Re: Reload bug

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

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