[llvm-commits] r55638 - /llvm/trunk/include/llvm/Function.h

[Duncan Sands]

Hi Devang,

> > I think specifying noinline or alwaysinline at a call site makes
> > sense.  It means: don't inline (or always inline) this callsite!
> > Thus you could have a function that is not itself marked noinline,
> > but a few special callsites that are marked noinline.  I see no
> > reason not to make these function attributes.
> 
> I do not see what additional value this adds in practice. IMO, let  
> caller's threshold influence decision here.

I agree that it's not very useful, but since you get it automagically
if you treat noinline/alwaysline like readonly/readnone/nounwind, then
why not?

> Function A calls Function B. If Function B's code is available and  
> inliner can inline B into A, then I view this as  - A is absorbing (or  
> digesting) B. B does not have much to say here. A is not destroying B  
> and other uses of B. This is my view, and I think you do not  
> completely agree with this. My view also makes new policy decisions  
> obvious.
> 
> 	define void @S() notes ("x86.sse3") { ... }
> 
> Here, the intent is simple - function S will run on a processor which  
> has sse3 support.
> 
> 	define void @NS() notes ("x86.no-sse") { ... }
> 
> Again, the intent is clear and simple - function NS is intended to run  
> on a processor that does not have SSE support. Do not use SSE  
> instructions.

I think it's important to distinguish between cases where the note is
required for correct behaviour, and where it simply indicates a preference.

If it denotes a preference then it doesn't matter much if the inliner
discards the note when inlining the function.  This is probably the
case for most codegen options - they are about performance/code size,
rather than about correctness.

That said, suppose I compile A without any particular sse flags (eg:
because it itself doesn't use any sse instructions).  Suppose B is
compiled with sse because it does vector operations.  If LTO results
in B being inlined into A, and that means that the vector operations
are codegened without sse support - well, someone will be upset.

Anyway, when might a note be required for correct behaviour?

One obvious case is -ffast-math.  Suppose B does some careful
floating point computation, and is not compiled with -ffast-math.
Suppose A does some relaxed floating point computations as well as
calling B, and is compiled with -ffast-math.  If B is inlined into
A then its code will be compiled using fast-math because A has the
fast-math note.  This may cause wrong results.

I suppose another example is whether libcall simplification may be
done (assuming this ends up as a function note).  If A was compiled
with libcall simplification, and B was compiled without libcall
simplification, then B is inlined into A, the result could be wrong
libcall optimization.

Another example is asm that requires a frame pointer (eg: because
the asm looks at stack contents).  You could mark the function with
a frame-pointer note, but then you would also have to mark the
function noinline in case it gets inlined into a function marked
no-frame-pointer.

On the whole, I think if some property is needed for an instruction
to work correctly, then it should be somehow marked on that instruction.
For example, floating point instructions can be marked with a 'fast'
flag if the result is allowed to be a bit wobbly.  Likewise, if it
is valid to perform libcall simplifications on a function call,
then the function call could be marked specially - for example, by
having it call a corresponding llvm intrinsic instead (eg: have
libcall simplification apply only to llvm.sin and not sin, and
have front-ends output llvm.sin if libcall simplification is desired).
And finally, asm that requires a frame pointer could get a flag
to that effect (eg: by marking that it clobbers esp).

Ciao,

Duncan.