[LLVMdev] Help with definition of subregisters; spill, rematerialization and implicit uses

[Quentin Colombet]

Hi Mikael,

On Aug 19, 2014, at 4:09 AM, Mikael Holmén <mikael.holmen at ericsson.com> wrote:

> Hi Quentin,
> 
> On 08/15/14 19:01, Quentin Colombet wrote:
> [...]
>>> The question is: How should true subregister definitions be
>>> expressed so that they do not interfere with each other? See the
>>> detailed problem description below.
>> 
>> We do have a limitation in our current liveness tracking for
>> sub-register. Therefore, I am not sure that is possible.
>> 
>> Conceptually, what you want is:
>> Reg5:hi16<def,read-undef>
>> Reg5:lo16<def,read-undef>
>> 
>> However, I guess this wouldn’t be supported, because it would mean that
>> we do not care about the value of hi16 at the definition of Reg5:lo16.
>> This is true, but after this definition we do care about hi16 and I am
>> afraid read-undef does not convey the right information for the
>> subsequent uses of Reg5.
>> 
>> You can give it a try and see how it goes.
> 
> I tried setting isUndef to trie when handling INSERT_SUBREG in TwoAddressInstructioPass.cpp, but then I run into stuff like this instead:
> 
> 832B            %vreg50:hi16<def,read-undef> = COPY %vreg0
> 848B            ...
> 864B            %vreg19<def,dead> = COPY %vreg50
> 880B            %vreg19:lo16<def,read-undef> = COPY %vreg73
> 896B            ...
> 912B            mv_a32_r16_rmod1 %vreg19, %vreg20
> 
> ...
> 
> *** Bad machine code: Multiple connected components in live interval ***
> - function:    fixedconv
> - interval:    %vreg19 [864r,864d:0)[880r,1024r:1)  0 at 864r 1 at 880r
> 0: valnos 0
> 1: valnos 1
> 
> So here, both the setting of the hi16 and lo16 parts are marked with read-undef, as wanted. However
> 
> 864B            %vreg19<def,dead> = COPY %vreg50
> 
> looks suspicious to me. It's like it thinks that
> 
> 880B            %vreg19:lo16<def,read-undef> = COPY %vreg73
> 
> is redefining the whole vreg19, not only the lo16 part, and since this instruction has read-undef, it thinks no part of vreg19, not even hi16 is live over instruction 880.

I was afraid something like this would happen.
Your interpretation is correct.

This confirms that the semantic of read-undef flag means that the others part of the register are undef, and thus nothing live through. The bottom line is currently you cannot represent what you want.

It seems that you will have to debug further the *** Bad machine code: Instruction loads from dead spill slot *** before we can be of any help.

Thanks,

-Quentin

> 
>>> 
>>> isUndef() will return false and getSubReg() true, and thus readsReg()
>>> true and the reload is inserted.
>>> 
>>> Then we get
>>> 
>>> *** Bad machine code: Instruction loads from dead spill slot ***
>>> 
>>> because the spill slot has not been written.
>> 
>> This is weird. Any chance you could share a test case?
> 
> Unfortunately not. I'm running our out-of-tree backend and I've no idea if anything like this ever happens in other backends :(
> 
> Thanks!
> /Mikael
>