[llvm] r189101 - Add function attribute 'optnone'.

[Andrea_DiBiagio at sn.scee.net]

Hi Duncan,

> From: Duncan Sands <duncan.sands at gmail.com>
> Hi Andrea,
> 
> On 23/08/13 13:53, Andrea Di Biagio wrote:
> > Author: adibiagio
> > Date: Fri Aug 23 06:53:55 2013
> > New Revision: 189101
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=189101&view=rev
> > Log:
> > Add function attribute 'optnone'.
> >
> > This function attribute indicates that the function is not optimized
> > by any optimization or code generator passes with the
> > exception of interprocedural optimization passes.
> 
> 
> > --- llvm/trunk/docs/LangRef.rst (original)
> > +++ llvm/trunk/docs/LangRef.rst Fri Aug 23 06:53:55 2013
> > @@ -879,6 +879,17 @@ example:
> >       This function attribute indicates that the function never 
returns
> >       with an unwind or exceptional control flow. If the function does
> >       unwind, its runtime behavior is undefined.
> > +``optnone``
> > +    This function attribute indicates that the function is not 
optimized
> > +    by any optimization or code generator passes with the
> > +    exception of interprocedural optimization passes.
> 
> to me this sounds like "if LLVM didn't optimize the function then it 
adds
> optnone to it".  How about this:
>    that the function is not optimized
> ->
>    that the function must not be optimized

I think you are definitely right, I will change it as you suggested.

> 
> Also, I think talking about interprocedural optimization passes here
> is a mistake.  What does that mean exactly: how many people know what
> is an interprocedural optimization pass and what isn't?  I suggest you
> cheat and say that the function body is not optimized.  I came up with
> this but I'm not sure it's much of an improvement:
> 
> +``optnone``
> +    This function attribute tells the optimizers not to modify the body 
of
> +    the function.  The optimizers are still allowed to analyze the 
function,
> +    for example to determine if it writes to memory, and to delete it 
if it
> +    is unused.  But the instructions composing the function should be 
left
> +    alone.

I think that rewriting the description of the optnone attribute as you 
suggested is ok and it is definitely an improvement over my previous 
description.

As you said, as long as the instructions within the optnone functions are 
left unchanged, it will always be possible to analyze them to simplify 
code from other functions etc.
I think the goal is to avoid the case where the presence of optnone 
functions in a module negatively affect how other functions are optimized. 

I agree that a GlobalDCE pass should be allowed to remove a dead function 
even if it marked optnone.

My question is whether Module Passes like the DAE Pass (Dead Argument 
Elimination pass) should be allowed to remove unused arguments from 
optnone functions. I personally don't have a strong opinion on this; 
however if we allow DAE to remove unused arguments, then we should decide 
what to do with other Module Passes as well.
For example, is it ok to allow the IPCP (InterProcedural Constant 
Propagation pass) to propagate constants inside optnone functions?
If we don't allow it then we preserve the instructions in the optnone 
function, however we may not spot opportunities for removing unused 
arguments when running the DAE Pass.

> > +    This attribute cannot be used together with the ``alwaysinline``
> > +    attribute; this attribute is also incompatible
> > +    with the ``minsize`` attribute and the ``optsize`` attribute.
> > +
> > +    The inliner should never inline this function in any situation.
> > +    Only functions with the ``alwaysinline`` attribute are valid
> > +    candidates for inlining inside the body of this function.
> 
> Ha, "alwaysinline" strikes again!  What happens when the unmovable
> "optnone" meets the irrestistable "alwaysinline"?  Maybe the compiler
> should just error out in this case: declare that this combination is
> invalid and have the verifier catch it.

Yes, those attributes are incompatible and r189101 introduces rules in the 
Verifier to catch when attribute 'alwaysinline' is specified when 
'optnone' is also present.
If for example I define a function with both attributes optnone and 
alwaysinline, then the verifier will be able to catch it and print out 
that "Attributes 'alwaysinline and optnone' are incompatible!".

Do you think I should change/rephrase that part in the documentation?

Please let me know what do you think.

Thanks!
Andrea


**********************************************************************
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify postmaster at scee.net
This footnote also confirms that this email message has been checked for 
all known viruses.
Sony Computer Entertainment Europe Limited
Registered Office: 10 Great Marlborough Street, London W1F 7LP, United 
Kingdom
Registered in England: 3277793
**********************************************************************

P Please consider the environment before printing this e-mail