[PATCH 5/5] Make ipa-sra observe the used parameter.

Joseph S. Myers joseph@codesourcery.com
Thu Aug 6 13:45:00 GMT 2009


On Thu, 6 Aug 2009, Richard Guenther wrote:

> On Wed, 5 Aug 2009, Martin Jambor wrote:
> 
> > This  is to  a big  extent  an RFC  patch which  makes IPA-SRA  ignore
> > parameters  decorated with  the  attribute "used."   Unlike the  other
> > ones, it also needs an approval from a C front-end maintainer.
> 
> The middle-end parts are ok.  Joseph, can you ack the rest?

I can't make sense from the provided documentation what the purpose is of 
the attribute I am supposed to be reviewing.

> > Index: mine/gcc/doc/extend.texi
> > ===================================================================
> > --- mine.orig/gcc/doc/extend.texi
> > +++ mine/gcc/doc/extend.texi
> > @@ -4077,8 +4077,10 @@ to be possibly unused.  GCC will not pro
> >  variable.
> >  
> >  @item used
> > -This attribute, attached to a variable, means that the variable must be
> > -emitted even if it appears that the variable is not referenced.
> > +This attribute, attached to a variable, means that the variable must
> > +be emitted even if it appears that the variable is not referenced.
> > +When attached to a function parameter, it means that the parameter
> > +must not be removed by optimizations such as IPA-SRA.

This could do with a cross-reference to part of the user manual explaining 
what "IPA-SRA" is.  But in what circumstances would a user wish to use 
this attribute on a parameter, given that the optimization is enabled?

I presume that as a matter of correctness the optimization is only applied 
to static functions whose address does not escape, as the ABI of other 
functions is visible to other translation units.  So the attribute would 
only seem to make sense when the parameter is used in some way behind the 
compiler's back.  I can think of three possibilities:

* The function is called from inline assembly code in that source file 
(and the name is hardcoded in that code rather than the address being 
passed as an operand to the asm).

* Register variables placed in an explicit register with asm are used as 
aliased to the parameter register (see glibc ports MIPS longjmp for an 
example of this rather fragile practice - not of course in a static 
function, so not affected by IPA-SRA anyway).

* The function is intended to be called from the debugger with all the 
parameters with which it is declared.  I take it debug info for a modified 
function will declare it as having the modified parameters, so the 
debugger can at least tell the user if they try to call a modified 
function with original parameters?  Is this tested in the testsuite?

However, these seem to be properties of the whole function as much as of 
an individual parameter; it's no good to preserve one parameter for inline 
asmr or register variables if the one before is removed so the parameter 
is now in the wrong register.  So why would someone wish to preserve a 
single parameter rather than marking the whole function with a "keep this 
function and don't change its ABI" attribute?  It's not just keeping a 
parameter fro being removed either; surely you need to prevent all the 
other modificiations, short of removal, that the optimization might do?

Whatever the reason, the documentation should make clear why someone might 
wish to use the attribute.  Cross-references to it from elsewhere may also 
be useful, e.g. from the inline asm documentation to say that you need to 
do this if calling a static function from inline asm.

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list