On Thu, Sep 15, 2011 at 4:09 PM, Vladimir Makarov <vmaka...@redhat.com> wrote:
> On 09/15/2011 03:06 PM, Peter Bigot wrote:
>>
>> 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 should not be happening.  It is a bug.  It should be fixed in RA (IRA or
> reload).  IRA/reload works for many targets where the same situation occurs.
>  So it is hard to say what is wrong without more info.

Based on what you've said I've provided source and the before/after
IRA dump files in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427.
I'll continue to dig into this; suggestions welcome.

Peter

> Although RA is directed by many machine-dependent macros and one macro might
> return a wrong value (e.g.  number registers needed to hold value of a
> mode).  But it is less probable.

Reply via email to