Re: Vector Comparison patch

[Richard Guenther <richard dot guenther at gmail dot com>]

On Thu, Sep 29, 2011 at 12:00 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Sep 28, 2011 at 4:23 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Mon, Sep 26, 2011 at 5:43 PM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Mon, Sep 26, 2011 at 4:25 PM, Richard Guenther
>>> <richard.guenther@gmail.com> wrote:
>>>> On Wed, Sep 7, 2011 at 5:06 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
>>>>> This looks like it has the same issue with maybe needing to use
>>>>> TYPE_MAIN_VARIANT in type comparisons as the shuffle patch.
>>>>
>>>> I don't think so, we move qualifiers to the vector type from the element type
>>>> in make_vector_type and the tests only look at the component type.
>>>>
>>>> I am re-testing the patch currently and will commit it if that succeeds.
>>>
>>> Unfortunately gcc.c-torture/execute/vector-compare-1.c fails with -m32
>>> for
>>>
>>> ? ?vector (2, double) d0;
>>> ? ?vector (2, double) d1;
>>> ? ?vector (2, long) idres;
>>>
>>> ? ?d0 = (vector (2, double)){(double)argc, ?10.};
>>> ? ?d1 = (vector (2, double)){0., (double)-23};
>>> ? ?idres = (d0 > d1);
>>>
>>> as appearantly the type we chose to assign to (d0 > d1) is different
>>> from that of idres:
>>>
>>> /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.c-torture/execute/vector-compare-1.c:118:5:
>>> error: incompatible types when assigning to type '__vector(2) long
>>> int' from type '__vector(2) long long int'^M
>>>
>>> Adjusting it to vector (2, long long) otoh yields, for -m64:
>>>
>>> /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.c-torture/execute/vector-compare-1.c:118:5:
>>> error: incompatible types when assigning to type '__vector(2) long
>>> long int' from type '__vector(2) long int'
>>>
>>> But those two types are at least compatible from their modes. ?Joseph,
>>> should we accept mode-compatible types in assignments or maybe
>>> transparently convert them?
>>
>> Looks like we have a more suitable solution for these automatically
>> generated vector types - mark them with TYPE_VECTOR_OPAQUE.
>>
>> I'm testing the following incremental patch.
>>
>> Richard.
>>
>> Index: gcc/c-typeck.c
>> ===================================================================
>> --- gcc/c-typeck.c.orig 2011-09-28 16:22:10.000000000 +0200
>> +++ gcc/c-typeck.c ? ? ?2011-09-28 16:18:39.000000000 +0200
>> @@ -9928,8 +9928,10 @@ build_binary_op (location_t location, en
>> ? ? ? ? ? ? }
>>
>> ? ? ? ? ? /* Always construct signed integer vector type. ?*/
>> - ? ? ? ? ?intt = c_common_type_for_size (TYPE_PRECISION (TREE_TYPE
>> (type0)), 0);
>> - ? ? ? ? ?result_type = build_vector_type (intt, TYPE_VECTOR_SUBPARTS (type0));
>> + ? ? ? ? ?intt = c_common_type_for_size (GET_MODE_BITSIZE
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(TYPE_MODE (TREE_TYPE (type0))), 0);
>> + ? ? ? ? ?result_type = build_opaque_vector_type (intt,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE_VECTOR_SUBPARTS (type0));
>> ? ? ? ? ? converted = 1;
>> ? ? ? ? ? break;
>> ? ? ? ? }
>> @@ -10063,8 +10065,10 @@ build_binary_op (location_t location, en
>> ? ? ? ? ? ? }
>>
>> ? ? ? ? ? /* Always construct signed integer vector type. ?*/
>> - ? ? ? ? ?intt = c_common_type_for_size (TYPE_PRECISION (TREE_TYPE
>> (type0)), 0);
>> - ? ? ? ? ?result_type = build_vector_type (intt, TYPE_VECTOR_SUBPARTS (type0));
>> + ? ? ? ? ?intt = c_common_type_for_size (GET_MODE_BITSIZE
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(TYPE_MODE (TREE_TYPE (type0))), 0);
>> + ? ? ? ? ?result_type = build_opaque_vector_type (intt,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE_VECTOR_SUBPARTS (type0));
>> ? ? ? ? ? converted = 1;
>> ? ? ? ? ? break;
>> ? ? ? ? }
>
> That doesn't seem to work either. ?Because we treat the opaque and
> non-opaque variants of vector<int> as different (the opaque type isn't
> a variant type of the non-opaque one - something suspicious anyway).
>
> I'm going to try to apply some surgery on how we build opaque variants
> and then re-visit the above again.

Bootstrapped and tested on x86_64-unknown-linux-gnu and installed.

Richard.

> Richard.
>