[LLVMdev] Problem with cross class joins in the RegisterCoalescer

[Patrik Hägglund H]

Thanks!

Our bug is now fixed. Our getMatchingSuperRegClass is huge (more than 300 lines), messy, and incomplete.

> Or you could just rebase. On trunk, TableGen writes this difficult function for you.

That in itself would be a compelling reason to get the rebase to trunk done. I just curious how large the generated version will be. :-)

/Patrik Hägglund

-----Original Message-----
From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] 
Sent: den 19 januari 2012 16:46
To: Patrik Hägglund H
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Problem with cross class joins in the RegisterCoalescer

On Jan 19, 2012, at 2:16 AM, Patrik Hägglund <patrik.h.hagglund at ericsson.com> wrote:

> Is it intended that in some cases it is necessary to use
> "-disable-cross-class-join" to be sure the resulting code is ok?

No.

> I have several cases where cross class joins are carried out that makes
> the code turn out illegal, because the "new" register class is not
> allowed in all instructions where it is now used.
> 
> For example, by joining %vreg4, %vreg7 and %vreg9 the following code
> 
>      %vreg7<def> = COPY %vreg4:lo16; aNl_0_7:%vreg7 aN32_0_7:%vreg4
>      %vreg9<def> = COPY %vreg7; rN:%vreg9 aNl_0_7:%vreg7
>      %vreg17<def> = load %vreg9<kill>; aN40_0_7:%vreg17 rN:%vreg9
> 
> is turned into
> 
>      %vreg17<def> = load %vreg4:lo16<kill>; aN40_0_7:%vreg17 
> aN32_0_7:%vreg4
> 
> The load instruction however, can only use registers from the rN class,
> but the coalescer has changed so it now uses the lo16 part of a aN32
> register (which it cannot).

When sub-registers are involved, the coalescer uses the getMatchingSuperRegClass hook to determine if the cross class join is possible, and what the resulting register class should be. In this case it would call

  getMatchingSuperRegClass(aN32_0_7, aNl_0_7, lo16)

Check your implementation of that hook, and reread the comment describing what it does. It is quite tricky to get it right. Or you could just rebase. On trunk, TableGen writes this difficult function for you.

> So, should this not happen, or is the flag needed, or is this just a
> sign that we have a really weird or buggy register model?

We can handle weird, but not buggy. :-)