2015-09-18 19:50 GMT+03:00 Richard Henderson <r...@redhat.com>:
> On 09/18/2015 06:21 AM, Ilya Enkovich wrote:
>>>> +machine_mode
>>>> +default_get_mask_mode (unsigned nunits, unsigned vector_size)
>>>> +{
>>>> + unsigned elem_size = vector_size / nunits;
>>>> + machine_mode elem_mode
>>>> + = smallest_mode_for_size (elem_size * BITS_PER_UNIT, MODE_INT);
>>>
>>> Why these arguments as opposed to passing elem_size? It seems that every
>>> hook
>>> is going to have to do this division...
>>
>> Every target would have nunits = vector_size / elem_size because
>> nunits is used to create a vector mode. Thus no difference.
>
> I meant passing nunits and elem_size, but not vector_size. Thus no division
> required. If the target does require the vector size, it could be obtained by
> multiplication, which is cheaper. But in cases like this we'd not require
> either mult or div.
OK
>
>>>> @@ -1885,7 +1885,9 @@ expand_MASK_LOAD (gcall *stmt)
>>>> create_output_operand (&ops[0], target, TYPE_MODE (type));
>>>> create_fixed_operand (&ops[1], mem);
>>>> create_input_operand (&ops[2], mask, TYPE_MODE (TREE_TYPE (maskt)));
>>>> - expand_insn (optab_handler (maskload_optab, TYPE_MODE (type)), 3, ops);
>>>> + expand_insn (convert_optab_handler (maskload_optab, TYPE_MODE (type),
>>>> + TYPE_MODE (TREE_TYPE (maskt))),
>>>> + 3, ops);
>>>
>>> Why do we now need a conversion here?
>>
>> Mask mode was implicit for masked loads and stores. Now it becomes
>> explicit because we may load the same value using different masks.
>> E.g. for i386 we may load 256bit vector using both vector and scalar
>> masks.
>
> Ok, sure, the mask mode is needed, I get that. But that doesn't answer the
> question regarding conversion. Why would convert_optab_handler be needed to
> *change* the mode of the mask. I assume that's not actually possible, with
> the
> target hook already having chosen the proper mode for the mask.
There is no any conversion here, maskload_optab is a convert_optab
because it uses two modes, one for value and the other one for mask.
Ilya
>
>
> r~
