Re: Reload bug

[Jan Hubicka <jh at suse dot cz>]

> > What would prevent it from match on (subreg:DI (reg eax) 4)?
> 
> GET_MODE_SIZE (GET_MODE (inner)) / UNITS_PER_WORD == 2
> HARD_REGNO_NREGS (REGNO (inner), GET_MODE (inner)) == 2

Hmm, I guess I see it finally :)  Thanks for the patience.

One problem is that reload is really dealing with the impossible subregs
incorrectly.  See simd-* testcases on gcc 3.2 compiled with SSE support
- the (subreg:DF (XMM0:V3DF) 8) is produced, passed trought reload and
then assembled as XMM0 as the registers are of size 16.  I think we
should at least abort when the SUBREG_BYTE is not represent via
subreg_regno_offset.  Will try to make patch for that in mainline.

Concerning this testcase, the reload used to manage to get around this
problem.  It didn't get around intentionally and just because the
instruction contrain does not accept SSE register so reload is needed
anyway.  The idea of reloading whole SSE register into integer is no-go
as can be see from the other testcases.  There are two cases when the
reload is really needed:
1) we are not able to access the SUBREG_BYTE part because of
   the problem above because SUBREG_BYTE is not divisible by size of the
   register (there is no way to get the size of the register, but I guess
   we can use GET_MODE_SIZE / HARD_REGNO_NREGS) and we will also need to
   compensate the lowparts,

   This is the problem we are seeing.  It is IMO questionable whether it
   is valid to see such scenario and whether local alloc can produce
   such a subregs that has no representation.  My CANNOT_CHANGE_MODE_P
   patch avoids that as it causes the problem described above.

2) We are outputing into the register and the HARD_REGNO_NREGS is
   decreasing so we may convert subreg rewriting just part of the
   register to the subreg rewriting the lower part and clobbering upper
   part.  This is what I beleive the conditional was originally invented
   for.

Are we in the sync now?
It seems to be that the conditional is still overconservative for 2) as
it is still possible that the subreg is large enought to fit into
HARD_REGNO_NREGS of the destination and it now ignores 1).  It is
question whether 1) can legaly happen at all but I see it does for 3.2
(and does not for 3.3).
Honza
> 
> > That was the original problem that made me to change the behaviour (we
> > can't reload instructions needing two such subregged operands in -fPIC as
> > we simply run out of registers)
> 
> No, the problem was related to SSE regs.
> 
> -- 
> Eric Botcazou