On Mon, Apr 28, 2008 at 3:04 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > [ Apologies if this comes out twice. I posted this message last week, > but I think it was rejected because of a .pdf attachment. ] > > We have been bouncing ideas for a new mechanism to describe the behavior > of function calls so that optimizers can be more aggressive at call > sites. Currently, GCC supports the notion of pure/impure, > const/non-const, but that is not enough for various cases. > > The main application for this would be stable library code like libc, > that the compiler generally doesn't get to process. > > David sketched up the initial idea and we have been adding to it for the > last few weeks. At this point, we have the initial design ideas and > some thoughts on how we would implement it, but we have not started any > actual implementation work. > > The main idea is to add a variety of attributes to describe contracts > for function calls. When the optimizers read in the function > declaration, they can take advantage of the attributes and adjust the > clobbering effects of call sites. > > We are interested in feedback on the main idea and possible > implementation effort.
Roughly all of these attributes and ideas have been proposed before (by me, by zdenek, etc). Implementing the code to do stuff with the attributes is the easy part, and we've done some of it before (with a no_pointer_capture attribute, etc). The problem is three fold: 1. They all rely on slave labor for attributing headers for all the interesting platforms You can ameliorate some of this by having auto-annotations for the standard C library (ala builtins.def). 2. The number of interesting attributes is tremendous because of the amount of info you are trying to capture, and it is going to be very hard to get anyone to attribute an entire application, or even interesting functions, with all the right ones. 3. Most if not all of these attributes can be discovered by the compiler while we are compiling the libraries in question (or when your distro, etc does it), we just don't save it anywhere. It would be a huge boon if you included provisions for storing this info on the side somewhere, much like most linux distros these days keep debug info separate in /usr/lib/debug (and darwin allows you to put debug info in a differently named dir, etc). This would make most of the attributes not really necessary except for special cases, for the majority of our users. The last problem was easy, which is that nobody stepped up to solve all these problems :)
