[Bug rtl-optimization/34529] [4.1/4.2/4.3 Regression] Wrong code with altivec stores and offsets

["uweigand at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #8 from uweigand at gcc dot gnu dot org  2008-01-09 19:23 -------
This is a long-standing problem in gen_reload.  This routine fundamentally
assumes that every PLUS expression that describes a legitimate address can
be reloaded into a register without requiring any additional scratch registers.

It first attempts to generate a simple (set (...) (plus ...)) pattern.  If
the target does not accept this pattern, it tries as a fall-back to generate
a two-insn sequence to perform the load.

This code looks fundamentally broken to me, in that it does not check whether
the first of those two insns clobbers a register still required by the second.
However, even if such a check were added, at this point we could not actually
solve the problem, because it's far too late to allocate another register.

I ran into the same problem in the s390 back-end a long time ago, and solved
it by providing a back-end specific secondary reload rule (requiring a scratch
register) to reload PLUS patterns that require multiple instructions.

I think you'll have to do the same for rs6000.

(As a separate issue, the broken code in gen_reload should be replaced by an
abort -- at least back-ends where the secondary reload is missing would no
longer generate wrong code in that case.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529