This is the mail archive of the 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: unabl e to find a register to spill in class ‘SSE_FIRST_REG’

H.J. Lu wrote:
On Thu, Jun 18, 2009 at 10:37 AM, Jeff Law<> wrote:
H.J. Lu wrote:
On Wed, Jun 17, 2009 at 11:46 AM, Vladimir Makarov<>

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
task and potentially distracting compiler stability for many targets.
I'd rather avoid it even if it could solve other passes problems like
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
way is to fix in the combiner.

Is xmm0 the return value for the call?  ie, is it the SET_DEST of the

I looked at this problem. It looks like

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

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)
   (expr_list:REG_DEP_TRUE (use (reg:DI 5 di))

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?

The whole point of copying xmm0 to p666 is to free xmm0 so that it can be used by other insns.

Combine's removal of p666 = xmm0 is wrong as is changing the last insn above to use xmm0 instead of p666.


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