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

[Devang Patel]

On Oct 2, 2008, at 2:15 AM, Duncan Sands wrote:

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

I think, a check will require eventually, somwehere. I thought you'll  
ask this question, but let me ask it anyway - "What if a function  
marked as no-sse uses SSE builtin or SSE instruction in asm code?" :)

> 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 understand. IMO, inlining sse function into no-sse function is OK if  
we have mechanism to detect  SSE. As I mentioned above, we will need  
such check anyway, so we might as well use it here. If not then not a  
big deal.

However, I do not see anything wrong with inlining no-sse function  
into a sse function, which your approach will disallow as I understand.

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

:) Whenever we implement sse and no-sse attributes, we'll deal with  
details.
-
Devang