On Wed, Jun 22, 2016 at 05:29:59PM -0400, Michael Meissner wrote: > This code should fix the problem. It does not allow constants in the > arguments. Combine will create one of the vec_duplicate patterns with a > constant integer that will generate VSPLTIS<x> or XXSPLTIB/etc. I also > tightened the memory requirements to only allow indexed memory forms > during/after register allocation, since the instruction only uses indexed > addressing. > > I bootstrapped the compiler and ran make check with no regressions on a little > endian power8 system. Can I check it into trunk, and after an appropriate > waiting period check it into GCC 6.x if there were no issues?
If this works, that is marvelous. Okay for trunk and 6 later, thanks! Some tiny things... > * config/rs6000/predicates.md (splat_input_operand): Rework. > Don't allow constants, since the caller insns don't support > constants. During and after register allocation, only allow > indexed or indirect addresses, and not general addresses. Only > allow modes supported by the hardware. "caller insns"? > --- gcc/config/rs6000/rs6000.c (revision 237715) > +++ gcc/config/rs6000/rs6000.c (working copy) > @@ -6282,10 +6282,7 @@ gen_easy_altivec_constant (rtx op) > Return the number of instructions needed (1 or 2) into the address pointed > via NUM_INSNS_PTR. > > - If NOSPLIT_P, only return true for constants that only generate the > XXSPLTIB > - instruction and can go in any VSX register. If !NOSPLIT_P, only return > true > - for constants that generate XXSPLTIB and need a sign extend operation, > which > - restricts us to the Altivec registers. > + Return the constant that is being split via CONSTANT_PTR. > > Allow either (vec_const [...]) or (vec_duplicate <const>). If OP is a > valid > XXSPLTIB constant, return the constant being set via the CONST_PTR The CONST_PTR in that last line here is a misspelling of CONSTANT_PTR; this last part should be removed I think? Segher
