[Bug target/34091] [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at postreload.c:392
------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-22 03:12 -------
Subject: Re: New: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands,
at postreload.c:392
> > paer% gcc-4.2 -c -O s_texfilter.i
> > swrast/s_texfilter.c: In function â??sample_lambda_2dâ??:
> > swrast/s_texfilter.c:1420: error: insn does not satisfy its constraints:
> > (insn 2621 1258 1259 96 (set (mem/c:HI (plus:SI (reg/f:SI 30 %r30)
> > (const_int -474 [0xfffffe26])) [0 S2 A16])
> > (reg:HI 68 %fr22)) 53 {*pa.md:3126} (nil)
> > (nil))
> > swrast/s_texfilter.c:1420: internal compiler error: in
> > reload_cse_simplify_operands, at postreload.c:392
>
> The simplest fix is probably not to allow QImode and HImode values
> in the floating point registers as there's no instructions that operate
> on them.
I have implemented this, but it doesn't fix the problem. There
are problems in the backend handling spills for floating floating point
instructions. The issue has been around for a long time and never
resolved completely. It's papered over by register copies to
the general registers, and usually we don't get into trouble since
the architecture has quite a few registers.
I made an initial stab at fixing this by tightening up GO_IF_LEGITIMATE_ADDRESS
but I have run into problems with pseudos not being allocated hard registers.
This probably means I don't have the change quite right. I also have a
problem with paradoxical SUBREGS when the inner register is spilled. I'm
not clear on how this is to be handled on a big endian target with strict
alignment. The documentation says reload is supposed to prevent this from
happening, but it doesn't seem to. I see this with the testcase from this
PR. It's combine that creates the paradoxical SUBREG. Tracing back
why reload doesn't allocate a hard register is tough...
I'm going to try another approach. Use a lax definition for
GO_IF_LEGITIMATE_ADDRESS and try to fix things up using pa_secondary_reload.
I view this as a critical "target" bug. However, if we find a fix, I
don't think it should be applied to 4.2 and earlier since it's very likely
to break something else.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34091
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Reply to: