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~