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

[Duncan Sands]

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

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.

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

Ciao, Duncan.