This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]