[PATCH] #pragma vectorize

Nadav Rotem nrotem at apple.com
Tue Apr 22 14:15:13 PDT 2014


On Apr 22, 2014, at 2:11 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> From: "Tyler Nowicki" <tnowicki at apple.com>
>> To: "Chandler Carruth" <chandlerc at google.com>
>> Cc: "Hal Finkel" <hfinkel at anl.gov>, "Alexey Bataev" <alexey.bataev at intel.com>, "llvm cfe" <cfe-commits at cs.uiuc.edu>,
>> "Nadav Rotem" <nrotem at apple.com>
>> Sent: Tuesday, April 22, 2014 4:01:29 PM
>> Subject: Re: [PATCH] #pragma vectorize
>> 
>> 
>> I don’t think we should separate the option interleave from the
>> pragma vectorize. I mean, we should use the syntax #pragma vectorize
>> {interleave(_value_), width(_value_), enable, disable}, because
>> interleave and vectorization are related,
> 
> They are related, and even implemented by the same pass, but they are separate transformations. In fact, if you look at what the vectorizer does on its own, it far more often unrolls than it vectorizes. A user may want the interleaving even if they don't want vectorization (I often run into this).
> 
> Maybe we're looking at this the wrong way... what about?
> 
> pragma loop vectorize(width/enable/disable) interleave(count/enable/disable)

+1.  I like this proposal. 

> 
>> enable/disable don’t add
>> anything that isn’t already part of pragma vectorize enable/disable,
>> and specifying `#pragma vectorize disable’ would disable
>> interleaving.
> 
> But that's a bug. Are you sure that's what happens?
> 
>> 
>> 
>> As for safety, how about #pragma vectorize aggressive?
> 
> I don't like that; *that* sounds like a cost-model adjustment. The user is asserting something about the property of the loop, and we should try to capture that property. Although this may just be confusing, "vectorizable" is what we mean.
> 
> Thanks again,
> Hal
> 
>> 
>> 
>> Tyler
>> 
>> 
>> On Apr 22, 2014, at 12:56 PM, Chandler Carruth < chandlerc at google.com
>>> wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, Apr 22, 2014 at 12:47 PM, Hal Finkel < hfinkel at anl.gov >
>> wrote:
>> 
>> 
>> 
>>> I very much dislike the term 'interleave'. We had a great deal of
>>> trouble with this term in the C++ committee. There are execution
>>> models which want this information but do not guarantee
>>> "interleaved" execution, and this is observable.
>> 
>> In this particular case, I think this objection is misplaced. The
>> particular transformation that we're discussing is, literally, one
>> that provides interleaving of loop iterations. We could also call it
>> unsequenced (as I mentioned in some earlier e-mail), but in some
>> sense, this transformation is more specific than that.
>> 
>> 
>> 
>> I understand that. But I'm somewhat concerned *promising* it in the
>> pragma. It seems better to use a more generic term if there is a
>> good one that applies, and widen seems to.
>> 
>> 
>> 
>> 
>>> If this is just a cost model hint, I like "widen" quite a bit
>>> better,
>>> and maybe there is a way to work "hint" or "cost" into the name?
>> 
>> In some sense it is a cost model hint, but I'm not sure a user would
>> see it as such.
>> 
>> 
>> 
>> Yea, I see that too.
>> 
>> 
>> 
>> Using hint for the non-safety-asserting variants seems like a good
>> idea. We should be clear with the users whether they are providing
>> only a hint, or asserting something more.
>> 
>> 
>> Indeed. This is the key part.
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> 
>> 





More information about the cfe-commits mailing list