Avoid 1x vectors in tree-vect-generic (PR rtl-optimization/69896)

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  <jakub@redhat.com>

	PR rtl-optimization/69896
	* tree-vect-generic.c (get_compute_type): Avoid single element
	vector types.


	Jakub

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

On February 27, 2016 2:07:43 AM GMT+01:00, Bill Schmidt <wschmidt@linux.vnet.ibm.com> wrote:
>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?

OK.

Richard.

>> 2016-02-26  Jakub Jelinek  <jakub@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
>>