[llvm-commits] [llvm] r99345 - in /llvm/trunk/lib/Target/X86: CMakeLists.txt SSEDomainFix.cpp X86.h X86InstrInfo.cpp X86InstrInfo.h X86TargetMachine.cpp X86TargetMachine.h

[Evan Cheng]

On Mar 24, 2010, at 10:32 AM, Chris Lattner wrote:

> 
> On Mar 24, 2010, at 9:54 AM, Jakob Stoklund Olesen wrote:
> 
>>>> On Blackfin, the separate execution domains are explicit with disjoint register classes (D and P). That is not handled at all currently, and it needs to be taken care of before register allocation.
>>>> 
>>>> On the other hand, a late pass is really easy, and I can do a bit of inference across basic blocks too.
>>> 
>>> Both of these seem like instruction selections problems to me.  The problem is that after isel, we have MVT's on instruction sdnodes instead of register classes.  This problem seems exactly the same as selecting fpstack vs sse instructions for scalar floating point.
>> 
>> Yep.
>> 
>> If it is handled at isel time we could also handle different instruction patterns in different domains. Right now, I can't even replace shufps with pshufd because one is two-address and one is three-address.
> 
> Right.
> 
>> I think that cross-block inference is necessary to get good results. How are the plans for full-function isel? :-)
> 
> Exactly :)
> 
>> Note that the cost of crossing domains varies a lot.
>> 
>> On SSE/Nehalem it is a 2-cycle latency-only penalty on an out-of-order CPU.
>> On ARM it is a 20-cycle penalty on an in-order CPU.
>> On Blackfin a move instruction (or spill/restore) is required.
> 
> To be clear, I'm not objecting to the current plan of doing this as a late pass.  Changing isel to model this is a big change (but would solve other problems as well), so handling this late seems fine in the intermediate.  I just don't think we should tackle this as a scheduling problem.
> 

I don't see this as a isel problem. 1. Changing isel will only fix part of the problem, it will miss copies, loads, and stores introduced later. 2. We don't particularly care about choosing instructions based on the type information coming into isel. After all, users can write code that introduce domain crossing. Eliminating domain crossing is purely an optimization.

Evan


> -Chris  
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits