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

[Devang Patel]

On Sep 23, 2008, at 1:27 AM, Duncan Sands wrote:

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

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.


Now,

- if S calls NS then what to do about these notes ?

	Simple. S absorbs code from NS. After inlining you don't see any  
trace of NS inside S. And function S will run on a processor that has  
sse3 instructions so code generator is free to use sse3 instructions  
for the code copied from function NS.

- what if NS calls S ?

	Simple. After inlining, NS will run on a processor that has no sse  
support. So, inline S into NS only if code generator will not be  
forced to use SSE instructions for the code copied from S.

If XYZ calls S and NS then once again, XYZ's notes win.

-
Devang