llvm dev - May 2017 - Bug in TableGen RegisterBankEmitter

Hi,

I've run into an issue with the RegisterBankEmitter on the AMDGPU backend.
AMDGPU has a register class: VS_32, which is non-allocatable and contains
registers from both defined register banks (SGPRRegBank and VGPRRegBank).

The RegisterBankEmitter is adding this class to the CoverageData array
for both register classes, because it contains sub-registers of one
of the classes explicitly added to the RegisterBank, for example:

Added VS_32(explicit (VS_32) VReg_64 class-with-subregs: VReg_64)

This is a problem, because both RegisterBanks think they cover
VS_32, even though neither of them actually do.

What exactly is the best way to fix this?  It seems like we need some
additional checks in the RegisterBankEmitter to fix this, but it's not
clear to me what we should be checking for.

Thanks,
Tom

Hi Tom,
> On May 10, 2017, at 7:15 AM, Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi,
> 
> I've run into an issue with the RegisterBankEmitter on the AMDGPU
backend.
> AMDGPU has a register class: VS_32, which is non-allocatable and contains
> registers from both defined register banks (SGPRRegBank and VGPRRegBank).
> 
> The RegisterBankEmitter is adding this class to the CoverageData array
> for both register classes, because it contains sub-registers of one
> of the classes explicitly added to the RegisterBank, for example:
> 
> Added VS_32(explicit (VS_32) VReg_64 class-with-subregs: VReg_64)
> 
> This is a problem, because both RegisterBanks think they cover
> VS_32, even though neither of them actually do.
I agree this is a bug in the emitter. It should only add the subclasses of VS_32
that projects to V (resp. S) for the given subregs.

I let Daniel comment further.

Cheers,
-Quentin
> 
> What exactly is the best way to fix this?  It seems like we need some
> additional checks in the RegisterBankEmitter to fix this, but it's not
> clear to me what we should be checking for.
> 
> Thanks,
> Tom
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi Tom,

The output:
	Added VReg_64(explicit)
	Added VS_32(explicit (VS_32) VReg_64 class-with-subregs: VReg_64)
is saying that VS_32 was added because VReg_64 was explicitly specified and that
while inspecting VS_32, it noticed that every register in VS_32 was a
subregister of a register from VReg_64 using a single common subregister index.

I've added some more tracing to my local copy and it appears that the
subregister index it found in common was sub0. On the next line, (not shown
above) it also reports that they had sub1 in common too. I think the cause is
that AMDGPU is re-using the same subregister index for unrelated registers and
that tablegen assumes this means that they are compatible.

If that's right, one possible fix would be to rename some of the subregister
indices but that's likely to be quite painful. I'll have a think and see
if I can come up with something nicer.
> On 10 May 2017, at 16:58, Quentin Colombet <qcolombet at apple.com>
wrote:
> 
> Hi Tom,
> 
>> On May 10, 2017, at 7:15 AM, Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>> Hi,
>> 
>> I've run into an issue with the RegisterBankEmitter on the AMDGPU
backend.
>> AMDGPU has a register class: VS_32, which is non-allocatable and
contains
>> registers from both defined register banks (SGPRRegBank and
VGPRRegBank).
>> 
>> The RegisterBankEmitter is adding this class to the CoverageData array
>> for both register classes, because it contains sub-registers of one
>> of the classes explicitly added to the RegisterBank, for example:
>> 
>> Added VS_32(explicit (VS_32) VReg_64 class-with-subregs: VReg_64)
>> 
>> This is a problem, because both RegisterBanks think they cover
>> VS_32, even though neither of them actually do.
> 
> I agree this is a bug in the emitter. It should only add the subclasses of
VS_32 that projects to V (resp. S) for the given subregs.
> 
> I let Daniel comment further.
> 
> Cheers,
> -Quentin
> 
>> 
>> What exactly is the best way to fix this?  It seems like we need some
>> additional checks in the RegisterBankEmitter to fix this, but it's
not
>> clear to me what we should be checking for.
>> 
>> Thanks,
>> Tom
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170510/3c25c07f/attachment.html>