Re: [RFC] Modeling the behavior of function calls

[Marc Glisse <marc dot glisse+gcc at normalesup dot org>]

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