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

[Duncan Sands]

Hi Devang,

> > So what you are saying is: if function A is marked no-sse,
> > and it calls function B which is marked sse, than B will
> > not be inlined into A if B contains any floating point
> > operations (for example, a fp multiplication)?
> 
> Yes, if performance is important, otherwise let it use less efficient  
> floating point stack. So this is a policy decision. I understand that  
> you want inliner to not inline B into A in this case.

personally I don't much care, I'm just being obnoxious!
Your approach implies that the inliner needs to know all
about SSE, in particular that using SSE is more efficient
for certain constructs.  I just find that icky.  A quick
scan of X86ISelLowering.cpp gives:

(1) sse intrinsics (fair enough!)
(2) all floating point operations (including conversions
between integer and floating point)
(3) all vector operations (including integer operations)
(4) memset, memcpy and memmove (sse is used to codegen
these it seems)
(5) llvm.prefetch
(6) llvm.memory.barrier

While of course you can put this kind of list into the
inliner, in my opinion it's not a good design (plus it
has to be kept up to date).  Hopefully other codegen options
encoded as attributes won't need their own lists...

As you know I have an alternative approach which doesn't
require the inliner knowing this kind of stuff.  It does
however require being able to differentiate between three
cases: whether on the llvm-gcc command line
  - SSE was explicitly requested
  - no-SSE was explicitly requested
  - neither of the above was requested ("don't care" case).
I don't know if this is really feasible given the way the
llvm-gcc command line works - I didn't think about it at all.
But if it is feasible then I like it better (surprise surprise)!

I'm not going to mention it anymore because I'm tired of
this topic - I guess you are too! :)

Best wishes,

Duncan.