Richard Biener <richard.guent...@gmail.com> writes:
> On Mon, Sep 4, 2017 at 1:36 PM, Richard Sandiford
> <richard.sandif...@linaro.org> wrote:
>> There are at least a few places that want to create an integer vector
>> with a specified element size and element count, or to create the
>> integer equivalent of an existing mode. This patch adds helpers
>> for doing that.
>>
>> The require ()s are all used in functions that go on to emit
>> instructions that use the result as a vector mode.
>>
>> 2017-09-04 Richard Sandiford <richard.sandif...@linaro.org>
>>
>> gcc/
>> * machmode.h (mode_for_int_vector): New function.
>> * stor-layout.c (mode_for_int_vector): Likewise.
>> * config/aarch64/aarch64.c (aarch64_emit_approx_sqrt): Use it.
>> * config/powerpcspe/powerpcspe.c (rs6000_do_expand_vec_perm):
>> Likewise.
>> * config/rs6000/rs6000.c (rs6000_do_expand_vec_perm): Likewise.
>> * config/s390/s390.c (s390_expand_vec_compare_cc): Likewise.
>> (s390_expand_vcond): Likewise.
>>
>> Index: gcc/machmode.h
>> ===================================================================
>> --- gcc/machmode.h 2017-09-04 12:18:50.674859598 +0100
>> +++ gcc/machmode.h 2017-09-04 12:18:53.153306182 +0100
>> @@ -706,6 +706,21 @@ extern machine_mode bitwise_mode_for_mod
>>
>> extern machine_mode mode_for_vector (scalar_mode, unsigned);
>>
>> +extern opt_machine_mode mode_for_int_vector (unsigned int, unsigned int);
>> +
>> +/* Return the integer vector equivalent of MODE, if one exists. In other
>> + words, return the mode for an integer vector that has the same number
>> + of bits as MODE and the same number of elements as MODE, with the
>> + latter being 1 if MODE is scalar. The returned mode can be either
>> + an integer mode or a vector mode. */
>> +
>> +inline opt_machine_mode
>> +mode_for_int_vector (machine_mode mode)
>
> So this is similar to int_mode_for_mode which means...
>
> int_vector_mode_for_vector_mode?
I'd used that style of name originally, but didn't like it because
it gave the impression that the result would be a VECTOR_MODE_P.
mode_for_int_vector was supposed to be consistent with mode_for_vector.
>> +{
>
> Nothing prevents use with non-vector MODE here, can we place an assert here?
That was deliberate. I wanted it to work with scalars too, returning
a V1xx in that case.
>> + return mode_for_int_vector (GET_MODE_UNIT_BITSIZE (mode),
>> + GET_MODE_NUNITS (mode));
>> +}
>> +
>> /* A class for iterating through possible bitfield modes. */
>> class bit_field_mode_iterator
>> {
>> Index: gcc/stor-layout.c
>> ===================================================================
>> --- gcc/stor-layout.c 2017-09-04 12:18:50.675762071 +0100
>> +++ gcc/stor-layout.c 2017-09-04 12:18:53.153306182 +0100
>> @@ -517,6 +517,23 @@ mode_for_vector (scalar_mode innermode,
>> return mode;
>> }
>>
>> +/* Return the mode for a vector that has NUNITS integer elements of
>> + INT_BITS bits each, if such a mode exists. The mode can be either
>> + an integer mode or a vector mode. */
>> +
>> +opt_machine_mode
>> +mode_for_int_vector (unsigned int int_bits, unsigned int nunits)
>
> That's more vector_int_mode_for_size (...), no? Similar to int_mode_for_size
> or mode_for_size.
>
> Ok with those renamings. I wonder if int_vector_mode_for_vector_mode
> is necessary -- is calling vector_int_mode_for_size
> (GET_MODE_UNIT_BITSIZE (mode),
> GET_MODE_NUNITS (mode)) too cumbersome?
IMO yes :-) It's certainly longer than the equivalent int_mode_for_mode
expansion.
Thanks,
Richard
