This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: PR target/40470: unable to find a registe r to spill in class ‘SSE_FIRST_REG’


On Thu, Jun 18, 2009 at 10:37 AM, Jeff Law<law@redhat.com> wrote:
> H.J. Lu wrote:
>>
>> On Wed, Jun 17, 2009 at 11:46 AM, Vladimir Makarov<vmakarov@redhat.com>
>> wrote:
>>
>>>
>>> Jeff Law wrote:
>>>
>>>>
>>>> Vladimir Makarov wrote:
>>>>
>>>>>
>>>>> IRA does not generate spill code for insn constraints. ?Reload does it.
>>>>> ?To fix it in reload (spill and restore hard registers) is not a
>>>>> trivial
>>>>> task and potentially distracting compiler stability for many targets.
>>>>> ?So
>>>>> I'd rather avoid it even if it could solve other passes problems like
>>>>> 1st
>>>>> insn scheduling for x86/x86_64.
>>>>>
>>>>> The originally problem occurs in the combiner (it propagates xmm0 usage
>>>>> right after a call through the insn in question). ?So imho I think the
>>>>> best
>>>>> way is to fix in the combiner.
>>>>>
>>>>
>>>> Is xmm0 the return value for the call? ?ie, is it the SET_DEST of the
>>>> call?
>>>>
>>>>
>>>>
>>>
>>> I looked at this problem. ?It looks like
>>>
>>> xmm0=call
>>> p666= xmm0
>>> ...
>>> insn in the question (spill failure because it needs xmm0)
>>> ...
>>> = p666, dead p666
>>>
>>> The combiner removes p666=xmm0 and uses xmm0 instead of p666 in the last
>>> insn.
>>>
>>>
>>
>> xmm0 is used for function return:
>>
>> (call_insn 19 18 20 4 x.i:31 (set (reg:V2DI 21 xmm0)
>> ? ? ? ?(call (mem:QI (symbol_ref:DI ("load") [flags 0x41]
>> <function_decl 0x7ffff310c800 load>) [0 S1 A8])
>> ? ? ? ? ? ?(const_int 0 [0x0]))) 908 {*call_value_0_rex64}
>> (expr_list:REG_DEAD (reg:DI 5 di)
>> ? ? ? ?(nil))
>> ? ?(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
>> ? ? ? ?(nil)))
>>
>> xmm0 is also a fixed register for some SSE4 insns. Since
>> we don't assign xmm0 early for those insns, how can
>> combine do anything for them? I think the proper fix
>> is in RA/reload.
>>
>
> No. ?The right place to fix this is in combine until such time as we have a
> new reload pass. ? ? Combine has had code for decades to not extend the
> lifetime of a hard return value to avoid this exact set of problems. ?It's
> clearly not working and that's what needs to be fixed.
>

The return value in xmm0 is used in the following few insns which also
require the fixed xmm0 for a different operand. How does combine
know it shouldn't extend the lifetime of a hard return value when it is
used immediately in the next few insns?


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]