Altivec + varargs -> unrecognizable insn

[Zack Weinberg <zack at codesourcery dot com>]

I've got a test case here (varargs-7.c from the bundle of Altivec
tests I posted on Friday) which, when any level of optimization is
enabled, causes an unrecognizable insn ICE.

Initial RTL generation produces

(insn 33 32 34 (nil) (set (reg/v:V4SI 130)
        (mem/f:V4SI (reg/f:SI 113 virtual-incoming-args) 
         [0 p13+0 S16 A128]))
  -1 (nil)
  (expr_list:REG_EQUIV
      (mem/f:V4SI (reg/f:SI 113 virtual-incoming-args)
       [0 p13+0 S16 A128])
        (nil)))

Virtual register elimination turns this into

(insn 33 279 34 2 (nil) (set (reg/v:V4SI 130)
        (mem/f:V4SI (plus:SI (reg/f:SI 67 ap)
                (const_int 8 [0x8])) [0 p13+0 S16 A128])) -1 (nil)
    (expr_list:REG_EQUIV (mem/f:V4SI (plus:SI (reg/f:SI 67 ap)
                (const_int 8 [0x8])) [0 p13+0 S16 A128])
        (nil)))

This is unrecognizable, because the only addressing modes available
for Altivec load/store instructions are (reg) and (reg+reg); there is
no (reg+immediate).  The instruction remains unrecognized and
untouched until the lreg pass, at which point we abort in
extract_insn.

I imagine this is a problem with the machine description, but I don't
know what the right fix is.  It seems like the problem is within
reload's brief, but we never get to reload.  Suggestions?

(With optimization disabled, a completely different code sequence is
produced, which does not provoke the bug.)

zw