Re: [RFC][Scalar masks 1/x] Introduce GEN_MASK_EXPR.

[Ilya Enkovich <enkovich dot gnu at gmail dot com>]

2015-08-21 18:57 GMT+03:00 Jeff Law <law@redhat.com>:
> On 08/21/2015 06:30 AM, Ilya Enkovich wrote:
>>
>> 2015-08-20 21:41 GMT+03:00 Jeff Law <law@redhat.com>:
>>>>>
>>>>> 2015-08-17  Ilya Enkovich  <enkovich.gnu@gmail.com>
>>>>
>>>>
>>>>          * expr.c (expand_expr_real_2): Support GEN_MASK_EXPR.
>>>>          * gimple-pretty-print.c (dump_unary_rhs): Likewise.
>>>>          * gimple.c (get_gimple_rhs_num_ops): Likewise.
>>>>          * optabs.c: Include gimple.h.
>>>>          (vector_compare_rtx): Add OPNO arg.
>>>>          (get_gen_mask_icode): New.
>>>>          (expand_gen_mask_expr_p): New.
>>>>          (expand_gen_mask_expr): New.
>>>>          (expand_vec_cond_expr): Adjust vector_compare_rtx call.
>>>>          * optabs.def (gen_mask_optab): New.
>>>>          (gen_masku_optab): New.
>>>>          * optabs.h (expand_gen_mask_expr_p): New.
>>>>          (expand_gen_mask_expr): New.
>>>>          * tree-cfg.c (verify_gimple_assign_unary): Support
>>>> GEN_MASK_EXPR.
>>>>          * tree-inline.c (estimate_operator_cost): Likewise.
>>>>          * tree-pretty-print.c (dump_generic_node): Likewise.
>>>>          * tree-ssa-operands.c (get_expr_operands): Likewise.
>>>>          * tree.def (GEN_MASK_EXPR): New.
>>>
>>>
>>> A general question, would any of this likely help Yuri's work to optimize
>>> MASK_STORES?
>>
>>
>> If I remember correctly his optimization is for Haswell which doesn't
>> have scalar masks. But doing it with scalar masks would be simpler
>> because zero mask check becomes trivial.
>
> I was thinking mostly about the mask check.
>
>
>
>>> So if the target doesn't have suitable insns, what happens?  I suspect
>>> the
>>> answer is nothing useful.  In which case the question becomes what
>>> prevents
>>> the optimizers from generating a GEN_MASK_EXPR?  Maybe that'll become
>>> clear
>>> as I read the rest of the patches.
>>
>>
>> I don't expect other optimizer than vectorizer to generate it. And as
>> usually optab is checked before generating it.
>
> If we're checking an optab to drive an optimization, then we're probably on
> the wrong track.

That's totally similar to VEC_COND_EXPR which we generate comparison into.

>I think this ties into the overall discussion about
> whether or not to represent these masks in gimple or try to handle them
> later during gimple->rtl expansion.

Currently we don't have any abstraction for masks, it is supported
using vector of integers. When I expand it I have no idea whether it
is just a vector of integers to be stored or a mask to be used for
MASK_LOAD. Actually it may be used in both cases at the same time.

Handling it in RTL means we have to undo bool->int transformation made
in GIMPLE. For trivial cases it may be easy but in generic it can be
challenging.  I want to avoid it from the beginning.

Thanks,
Ilya

>
> Jeff