This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: PR target/40470: unabl e to find a register to spill in class ‘SSE_FIRST_REG’
H.J. Lu wrote:
On Wed, Jun 17, 2009 at 8:22 AM, Jeff Law<firstname.lastname@example.org> wrote:I am agree with Jeff and Richard. There is one more reason to avoid
using hard registers. Usage of hard registers tends to create more
spill failures in reload.
Steven Bosscher wrote:
On 6/17/09, Jeff Law <email@example.com> wrote:It'll completely disable the RTL loop optimizers. Granted this is less
Richard Guenther wrote:
On Wed, Jun 17, 2009 at 4:01 PM, H.J. Lu<firstname.lastname@example.org> wrote:Agreed. In fact, it can have horrific performance impacts.
Some SSE4 instructions have implicit XMM0 operand. This patch helps RA
deal with them by forcing operand into XMM0 during expand. OK for trunk
I don't think it's a particularly good idea to put things in hardregs
Why? Most optimizazions that can be done for this insn can only be
done on GIMPLE, right? And the insn must have that specific register.
So unless I am missing something, I don't see why this patch would do
important today than before, but it's still bad. And more importantly, the
register allocators and reload should be fixed to DTRT rather than hacking
I am all for it. Vladimir, how hard to fix RA for this?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.