On Mon, 28 Apr 2008, Diego Novillo wrote:
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.
Nice.
The last time I thought about something like this was for automatic
parallelization. In order to be allowed to automatically add openmp
directives to a loop, you need to determine that what is done in the loop
is safe to parallelize. There are some cases where things are obvious with
calls to pure/const functions. However, I was particularly interested in
the case where the loop may use functions which call malloc and thus
cannot be declared pure/const (I believe), although they should be safe to
parallelize (assuming your malloc is thread-safe).
I don't think I have seen in your proposal any attributes that would help
in this case, but I may have overlooked some. Note that I don't know what
exact contracts on functions would be most useful for this. It could be
considered an independent project, but I guess that if people have to
manually go through the code to add attributes, it would be better if the
list was as complete as possible (even if some attributes are ignored for
now) to start with so they don't have to go through the code again later
when we add yet another attribute.
--
Marc Glisse