[Bug target/34091] [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at postreload.c:392

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]



------- 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