On Apr 22, 2014, at 2:11 PM, Hal Finkel <[email protected]> wrote: > ----- Original Message ----- >> From: "Tyler Nowicki" <[email protected]> >> To: "Chandler Carruth" <[email protected]> >> Cc: "Hal Finkel" <[email protected]>, "Alexey Bataev" >> <[email protected]>, "llvm cfe" <[email protected]>, >> "Nadav Rotem" <[email protected]> >> 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 < [email protected] >>> wrote: >> >> >> >> >> >> >> >> On Tue, Apr 22, 2014 at 12:47 PM, Hal Finkel < [email protected] > >> 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 >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
