Reload bug

[Jan Hubicka]

> > 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?
> 
> I don't fully understand the second point. Could you give an example?

It would be something like (subreg:SI (reg:TI) 8))
that is "set 8-12th byte of TIregister) when HARD_REGNO_NREGS is 4, but
"set 8-12th byte and clobber 12th-16th byte) when HARD_REGNO_NREGS is 2.
Not sure if it happens in real code...

Honza
> 
> > 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).
> 
> Are you sure of that for 3.3? Because we will silently miscompile too if 
> there are a few leaks.
> 
> -- 
> Eric Botcazou