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

[Duncan Sands]

Hi Andrea,
>> +``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 don't think this is achievable.  If no optimizations have been run on
a function, most analyses will do a poor job on it.  And disabling inlining
of optnone functions clearly impacts optimization of the functions it would
otherwise have been inlined into.

>
> 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;

I also don't have an opinion on this.  It might be helpful to understand
better what optnone is good for, i.e. who wants this and why.

> 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?

I don't think doing IPCP makes any sense: if ordinary constant folding
within the function has been disabled, why should IPCP be enabled?

> 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.

There are many other things that would get in the way of DAE, eg that
simplifycfg hasn't zapped dead basic blocks that use the argument, that
instcombine hasn't zapped dead uses of the argument etc etc.  Basically
DAE isn't going to be able to do anything except in the most trivial
cases, and I think we're just going to have to live with that.

>
>>> +    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!".

I meant: what if the optnone function calls a function marked alwaysinline.
Inlining it into the optnone function changes the code of the optnone
function, so is contrary to the principal that optnone function bodies are
just left alone.

Ciao, Duncan.

>
> 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
>