On 08/21/2015 10:30 AM, Ilya Enkovich wrote:
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.
It is. The vectorizer is riddled with this stuff. Sigh. So I won't
consider this a negative for the scalar mask support.
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.
I wasn't suggesting handling them in RTL, but at the border between
gimple and RTL.
But if we can't reliably determine how a particular mask is going to be
used at that point, then doing things at the gimple/RTL border may be a
spectacularly bad idea ;-)
jeff