* IRA misses register range overlap
@ 2011-09-15 15:16 Peter Bigot
2011-09-15 15:35 ` Vladimir Makarov
0 siblings, 1 reply; 6+ messages in thread
From: Peter Bigot @ 2011-09-15 15:16 UTC (permalink / raw)
To: gcc
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?
Thanks.
Peter
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IRA misses register range overlap
2011-09-15 15:16 IRA misses register range overlap Peter Bigot
@ 2011-09-15 15:35 ` Vladimir Makarov
2011-09-15 19:07 ` Peter Bigot
2011-09-16 10:35 ` Peter Bigot
0 siblings, 2 replies; 6+ messages in thread
From: Vladimir Makarov @ 2011-09-15 15:35 UTC (permalink / raw)
To: Peter Bigot; +Cc: gcc
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.
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IRA misses register range overlap
2011-09-15 15:35 ` Vladimir Makarov
@ 2011-09-15 19:07 ` Peter Bigot
2011-09-15 21:10 ` Vladimir Makarov
2011-09-16 10:35 ` Peter Bigot
1 sibling, 1 reply; 6+ messages in thread
From: Peter Bigot @ 2011-09-15 19:07 UTC (permalink / raw)
To: Vladimir Makarov; +Cc: gcc
On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov <vmakarov@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.
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IRA misses register range overlap
2011-09-15 19:07 ` Peter Bigot
@ 2011-09-15 21:10 ` Vladimir Makarov
2011-09-15 22:26 ` Peter Bigot
0 siblings, 1 reply; 6+ messages in thread
From: Vladimir Makarov @ 2011-09-15 21:10 UTC (permalink / raw)
To: Peter Bigot; +Cc: gcc
On 09/15/2011 03:06 PM, Peter Bigot wrote:
> On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov<vmakarov@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.
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IRA misses register range overlap
2011-09-15 21:10 ` Vladimir Makarov
@ 2011-09-15 22:26 ` Peter Bigot
0 siblings, 0 replies; 6+ messages in thread
From: Peter Bigot @ 2011-09-15 22:26 UTC (permalink / raw)
To: Vladimir Makarov; +Cc: gcc
On Thu, Sep 15, 2011 at 4:09 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> On 09/15/2011 03:06 PM, Peter Bigot wrote:
>>
>> On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov<vmakarov@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IRA misses register range overlap
2011-09-15 15:35 ` Vladimir Makarov
2011-09-15 19:07 ` Peter Bigot
@ 2011-09-16 10:35 ` Peter Bigot
1 sibling, 0 replies; 6+ messages in thread
From: Peter Bigot @ 2011-09-16 10:35 UTC (permalink / raw)
To: Vladimir Makarov; +Cc: gcc
On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov <vmakarov@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.
>
> 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).
My investigation leads me to believe that IRA does fail to detect the
conflicts, as you suggested. I'm generating RTL that uses specific general
registers that are not distinguished by register classes or marked in the
insn constraints. This is to prepare for calls to support routines that
don't follow the standard ABI. (Perhaps this is the wrong way to solve
that problem, though I believe AVR and perhaps other platforms do this
as well.)
I've attached to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427 a patch
that augments ira-lives.c (process_single_reg_class_operands) to detect this
and mark the corresponding registers as conflicts. It works on this case, and
doesn't create any problems that are obvious to me.
I'd appreciate a review of whether this approach is right, or if the conflicts
should be recorded somewhere else.
Peter
>
> But having only info you provided it is very hard to say what is wrong.
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-09-16 10:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-15 15:16 IRA misses register range overlap Peter Bigot
2011-09-15 15:35 ` Vladimir Makarov
2011-09-15 19:07 ` Peter Bigot
2011-09-15 21:10 ` Vladimir Makarov
2011-09-15 22:26 ` Peter Bigot
2011-09-16 10:35 ` Peter Bigot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).