[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