Hi Hal,
Thanks for the reply.
> Maybe we're looking at this the wrong way... what about?
>
> pragma loop vectorize(width/enable/disable) interleave(count/enable/disable)
I like this more, especially because its clear it applies only to loops.
>
>> 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?
I could be mistaken. This is what is in LoopVectorize at the top of
processLoop()
if (Hints.Force == 0) {
DEBUG(dbgs() << "LV: Not vectorizing: #pragma vectorize disable.\n");
return false;
}
And the unrolling occurs later in processLoop(). I thought it was a feature…
but yea, lets fix it.
>
>>
>>
>> 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.
`nodependence’?
Thanks,
Tyler_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
