[PATCH] #pragma vectorize

[Tyler Nowicki]

Hi Aaron, Richard, Ben,

Thanks for all the feedback. I’ve tried to integrate all of your suggested. I may have missed some, please let me know if I did.

Please review the attached patch.

Tyler




>> +  // Add vectorize hints to the metadata on the conditional branch.
>> +  // Iterate in reverse so hints are put in the same order they appear.
>> +  SmallVector<llvm::Value*, 2> Metadata(1);
>> +  ArrayRef<const Attr*>::reverse_iterator I;
>> +  for (I = Attrs.rbegin(); I != Attrs.rend(); ++I) {
> 
> Check against rend() should be hoisted (or use a range-based loop with
> an adaptor).

Sorry, I don’t understand what you are suggesting. Do we not compare against rend() in the loop condition?


>> I’m pretty sure a spelling is required unless you are providing the base
>> class outside the td file. I’m looking at modifying the way pretty printing
>> works now to generate a printer that prints the pragma. But it seems bad to
>> specialize the code that generates the pretty printer for printing loop
>> pragmas
> 
> Why?

That part of tablegen probably shouldn’t be specialized for each type of pragma should it? But from your comment below it sounds like thats what you are thinking.

Perhaps we should provide a separate method for printing pragmas rather than using printPretty. Right now printPretty returns the attribute's text and StmtPrinter::VisitAttributeStmt puts that between ‘[[‘ and ‘]]’. We need some way of putting the pragmas prior to the attribute. We could first loop over all attributes calling printPragma, and then again using printPretty to generate the attributes. Where printPragma would generate directives like #pragma loop ...


>> and so it will still be necessary to make some kind of a call into
>> the LoopHintAttr to print the pragma.
> 
> So what I was envisioning was that there would be a Pragma spelling
> added to Attr.td, which ClangAttrEmitter.cpp could then key off of for
> everything which is spelling-specific (you can search for CXX11 or
> Declspec in the file and that should show you the places that may need
> modification). However, that's orthogonal to your functionality, and
> not really something you should have to implement yourself just to get
> this patch in. I just don't have the time to tackle it myself right
> now.

Sounds good. I started looking at this I have a basic patch for Pragma spelling. After #pragma loop I’ll look at that again.


> So I guess what I am saying is: once there's a new patch that
> addresses most of the concerns (aside from stuff like modifying the
> way the attr tablegen works), we can see if there's anything else
> blocking your patch. Don't worry about modifying tablegen for this,
> that's more a FIXME for the future.
> 
> ~Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140509/4165e8c7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pragma_loop-svn.patch
Type: application/octet-stream
Size: 43576 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140509/4165e8c7/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140509/4165e8c7/attachment-0001.html>