Vector shifting patch

[Richard Guenther]

On Thu, Oct 28, 2010 at 12:22 PM, Artem Shinkarov
<artyom.shinkaroff@gmail.com> wrote:
> On Wed, Oct 27, 2010 at 10:14 PM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
>> On Wed, 27 Oct 2010, Artem Shinkarov wrote:
>>
>>> Ok, then here are vector shifts only.
>>
>> This version is getting closer:
>>
>>> +In C it is possible to use shifting operators @code{<<, >>} on integer-type
>>
>> The comma should be outside @code: @code{<<}, @code{>>}.
>
> Fixed.
>
>>
>>> Index: gcc/testsuite/gcc.c-torture/execute/vector-shift2.c
>>> ===================================================================
>>> --- gcc/testsuite/gcc.c-torture/execute/vector-shift2.c       (revision 0)
>>> +++ gcc/testsuite/gcc.c-torture/execute/vector-shift2.c       (revision 0)
>>> @@ -0,0 +1,60 @@
>>> +/* dg-do run */
>>
>> dg- directives have no effect in gcc.c-torture/execute, and if they were
>> to have an effect they'd need to be properly marked up: { dg-do run }.
>
> Fixed. That was the copying issue.
>
>>
>>> Index: gcc/testsuite/gcc.dg/vector-shift2.c
>>> ===================================================================
>>> --- gcc/testsuite/gcc.dg/vector-shift2.c      (revision 0)
>>> +++ gcc/testsuite/gcc.dg/vector-shift2.c      (revision 0)
>>> @@ -0,0 +1,61 @@
>>> +/* { dg-do run } */
>>> +/* { dg-options "-fno-var-tracking-assignments" } */
>>
>> Why this option?  It seems to have no relation to the test.
>
> This option is because of the bug:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569
>
> If you compile the code from gcc/testsuite/gcc.dg/vector-shift2.c with
> combination "-g -O3" then you will have a compiler internal error. But
> this error has nothing to do with this patch.
>
>>
>> Apart from that the C front-end changes seem OK.
>>
>> --
>> Joseph S. Myers
>> joseph@codesourcery.com
>>
>
> Richard, could you please submit the patch?

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied as rev. 166061.

I had to fix gcc.dg/simd-1b.c which was testing for error on a now valid
vector - vector shift.  I also removed the -fno-var-tracking-assignments flag
and moved the testcase to the torture.

As of mixed shifts I think vector <<>> scalar is an obvious thing to support
as we do have both direct middle-end and target support for these.  For
scalar <<>> vector shifts we can't really allow truncation for scalar.
 So I think
with mixed scalar vector operations we have a third thing similar to
C integer promotions and C usual arithmetic conversions, namely vector
promotion rules which basically would say that for mixed scalar, vector
operands this promotion promotes the scalar to a vector with the same
number of elements as the other vector.  Now the question is whether
(and where) we would need to enforce that the resulting vector mode
is of the same size.  Considering

char c;
int i;
c << (vector int){1, 2, 3, 4};

which either would produce v4qi << v4si giving a v4qi result or
v4si << v4si giving a v4si result.  I _think_ the former makes more
sense from a language point of view (but is not nice to the target
support code which would prefer a v4si result).

I think we should deal with scalar <<>> vector and vector <<>> scalar
separately.

Richard.