[llvm-commits] Patch for X86 to use subregs

[Evan Cheng]

On Jul 30, 2007, at 3:10 PM, Christopher Lamb wrote:

>
> On Jul 30, 2007, at 2:40 PM, Evan Cheng wrote:
>
>>
>> I appreciate you're trying to think of ways to expand the use of
>> subreg work. But x86-64 implicit zero-extension is not the same
>> problem. Trying to solve the x86-64 optimization issue this way is
>> a unacceptable hack. Your subreg pass is a general pass. Please
>> keep it that way.
>
> Settled.
>
> There are other cases where I think it would be interesting to model
> implicit operations or more complex register constrains in a way that
> the register allocator an coalescing has a way to deal with them.

Certainly!

> For instance, the kind of constraints that cause MOV16to16_ to be
> necessary. Here I'd think that coalescing could be taught how to
> coalesce moves between register classes and sub classes of that class.

Right.

> Currently the following MOV16to16_  wouldn't be coalesced, though it
> could be, because CX is in class GR32_ and AX is in class GR32.
>
> CX = mov AX
>
> Coalescing would see this as
>
> GR32_:reg1025 = mov GR32:reg1024
>
> So it isn't as simple as it may seem at first because you'd
> potentially have to tighten the register class constraint on the def
> of reg1024, but I think it's doable...

It isn't particularly difficult to teach the coalescer to coalesce  
across different register classes. The difficult part is figuring out  
when it is profitable. We have tried to enable coalescing of  
instructions like MOV16to16_. But in some cases it end up hurting  
performance because the resultant live interval is longer and have  
fewer candidate registers for the allocator to target.

I think the answer is we must have a way to undo harmful coalescing  
decision. That is, live range splitting. Without the ability to undo,  
we shouldn't be any more aggressive about coalescing as we already are.

>
> There is an internal architecture here that it would be interesting
> to target with LLVM, but it happens to have a highly constrained
> register file, requiring many of these currently un-coalesced moves
> between register sub classes and their parent. Do you think I should
> open a PR on that?

Yes, please open an enhancement request and add your ideas. Thanks!

Evan

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