On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov <vmaka...@redhat.com> wrote:
> On 09/15/2011 11:16 AM, Peter Bigot wrote:
>>
>> In the msp430 back end, hard registers 4 through 15 are HImode, with
>> adjacent register sequences used for SImode and DImode. In preparation
>> for
>> a library call, I'm emitting RTL that assigns values directly to reg:SI 4.
>>
>> Despite that, in gcc 4.5.x IRA choses reg:HI 4 as the destination
>> for a pseudo-register for a preceding assignment, and does nothing to
>> preserve the value over the span where the register is part of an SI
>> value.
>> The subsequence:
>>
>> (insn 2 4 3 2 (set (reg/v:HI 38 [ x ])
>> (reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
>> (expr_list:REG_DEAD (reg:HI 15 r15 [ x ])
>> (nil)))
>>
>> (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
>>
>> (note 6 3 10 2 NOTE_INSN_DELETED)
>>
>> (insn 10 6 11 2 (set (reg:SI 8 r8)
>> (mem/c/i:SI (symbol_ref:HI ("seed") [flags 0x2]<var_decl
>> 0x7f032064f960 seed>) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
>> (nil))
>>
>> (insn 11 10 12 2 (set (reg:SI 4 r4)
>> (const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
>> (nil))
>>
>> with:
>>
>> insn=2, live_throughout: 1, dead_or_set: 15, 38
>> insn=10, live_throughout: 1, 38, dead_or_set: 8, 9
>> insn=11, live_throughout: 1, 8, 9, 38, dead_or_set: 4, 5
>> insn=12, live_throughout: 1, 38, dead_or_set: 4, 5, 6, 7, 8, 9, 10,
>> 11, 12, 13, 14, 15
>>
>> becomes:
>>
>> (insn 2 4 3 2 (set (reg/v:HI 4 r4 [orig:38 x ] [38])
>> (reg:HI 15 r15 [ x ])) test.c:28 21 {*movhi2}
>> (nil))
>>
>> (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
>>
>> (note 6 3 10 2 NOTE_INSN_DELETED)
>>
>> (insn 10 6 11 2 (set (reg:SI 8 r8)
>> (mem/c/i:SI (symbol_ref:HI ("seed") [flags 0x2]<var_decl
>> 0x7f032064f960 seed>) [2 seed+0 S4 A16])) test.c:14 24 {*movsi2}
>> (nil))
>>
>> (insn 11 10 12 2 (set (reg:SI 4 r4)
>> (const_int 33614 [0x834e])) test.c:14 24 {*movsi2}
>> (nil))
>>
>> and the subsequent reference to reg:HI 4 (formerly reg/v:HI 38) has value
>> 33614 instead of the user's parameter.
>>
>> Could somebody suggest where should I look to understand why this is
>> happening and how should it be fixed?
>>
> The best way is to file a bug to http://gcc.gnu.org/bugzilla/. You should
> submit the test (the smaller the test, the better) and how to reproduce it:
> how to build gcc (configure options) and how to call the built gcc to
> reproduce results.
Unfortunately, the former msp430 maintainers never pushed the back-end
upstream, so filing a bug on a target that isn't part of gcc is
unlikely to get much attention. It's also pretty specific to the
machine description, so I doubt it could be reproduced on another
target.
I was hoping for more of a "yes, that happens if you don't [missed
back-end requirement here]", or even a "no, that shouldn't be
happening".
It looks almost like the fact that I'm generating RTL that references
the hard registers directly is ignored by IRA for conflict resolution,
which seems to only occur among the registers that it's responsible
for assigning. I'll look again through the docs to see if there's
some hints that I'm missing a step.
If anybody else has further suggestions or insights I'd appreciate
them. Thanks.
Peter
> I think you could look at ira dump file and check that allocno for p38
> conflicting with hard reg 4 *and* 5. If it is not, the problem is in
> conflict calculation. Otherwise, it might be IRA hard register assignment
> or in reload (the worst case).
>
> But having only info you provided it is very hard to say what is wrong.
>
>
