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

[Mikael Holmén]

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.

>>
>> 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