This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][Scalar masks 1/x] Introduce GEN_MASK_EXPR.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Ilya Enkovich <enkovich dot gnu at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 18 Sep 2015 14:04:38 +0200
- Subject: Re: [RFC][Scalar masks 1/x] Introduce GEN_MASK_EXPR.
- Authentication-results: sourceware.org; auth=none
- References: <20150817162247 dot GA12565 at msticlxl57 dot ims dot intel dot com> <55D61F54 dot 1090802 at redhat dot com> <CAMbmDYaF2SwU3J4hA_S9gUEj6-i1paxLh1WQkf=do98gDgwzWA at mail dot gmail dot com> <55D74A71 dot 7060001 at redhat dot com> <CAMbmDYZPxfymsC4+nLsQ4Oy2+CqR8w=3rJZ8ty7h-zf=VfN7HA at mail dot gmail dot com> <55DCD7EA dot 8030907 at redhat dot com>
On Tue, Aug 25, 2015 at 11:02 PM, Jeff Law <law@redhat.com> wrote:
> 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.
Hey, just because it's already bad don't make it worse!
>>
>>> 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 ;-)
Yeah, I also see Ilyas point here. Basically the new integer masks are
generated by if-conversion only. What I was suggesting is to differentiate
both cases by making vector comparisons always result in vector<bool>.
Thus if you have
if (a < b || d > e)
x = c;
then vectorized if-converted code would generate
vector<bool> cnd = a < b;
vector<bool> cnd2 = d > e;
vector<bool> cnd3 = cnd | cnd2;
x = cnd3 ? c : x;
when the target supports vector<bool> and otherwise
vector<int> cnd = a < b ? -1 : 0;
vector<int> cnd2 = d > e ? -1 : 0;
vector<int> cnd3 = cnd | cnd2;
x = cnd3 ? c : x;
which means only VEC_COND expr would support both kind of masks
(well, and the IFNs for masked loads/stores). Basically the vectorizer
needs to handle vectorizing conditions like
cnd = a < b;
dependent on target support for masks (that is vectorizing of 'bool'
operations).
Reworking the existing vectorization of bool operations to not depend
on pattern detection would be a first step (and already soving a few
PRs on the way).
Richard.
>
> jeff