Also tested with powerpc64le-unknown-linux-gnu native bootstrap with no regressions, where it fixes this bug as well as the (reopened) PR69613.
Bill On Sat, 2016-02-27 at 00:04 +0100, Jakub Jelinek wrote: > Hi! > > On ppc64, the widest (and only) supported vector mode for __int128 > element type is V1TImode, and there is a V1TImode or opcode > and a couple of others, but IMNSHO it is highly undesirable to lower > BLKmode (say 2xTI, 4xTI etc.) generic vectors to V1TI instead of > TI, there are no advantages in doing that and apparently lots of various > bugs (the PR contains a WIP partial patch to fix some of them, but that is > just a tip of an iceberg, apparently lots of the folding etc. code > is returning sometimes a 1x vector type when it should be returning the > element type or vice versa, if CTOR contains 1x VECTOR_CSTs, there are > issues too etc. > > So while I think it is desirable to fix all those V1?? handling issues > eventually, IMHO it is right to also just use element type instead > of 1x vectors during the generic vector lowering. > > Bootstrapped/regtested on x86_64-linux and i686-linux and tested on the > testcase using powerpc64le-linux cross, ok for trunk? > > 2016-02-26 Jakub Jelinek <ja...@redhat.com> > > PR rtl-optimization/69896 > * tree-vect-generic.c (get_compute_type): Avoid single element > vector types. > > --- gcc/tree-vect-generic.c.jj 2016-01-04 14:55:52.000000000 +0100 > +++ gcc/tree-vect-generic.c 2016-02-26 21:11:36.694482256 +0100 > @@ -1405,6 +1405,7 @@ get_compute_type (enum tree_code code, o > if (vector_compute_type != NULL_TREE > && (TYPE_VECTOR_SUBPARTS (vector_compute_type) > < TYPE_VECTOR_SUBPARTS (compute_type)) > + && TYPE_VECTOR_SUBPARTS (vector_compute_type) > 1 > && (optab_handler (op, TYPE_MODE (vector_compute_type)) > != CODE_FOR_nothing)) > compute_type = vector_compute_type; > > Jakub >
