[PATCH] #pragma vectorize

[Aaron Ballman]

On Thu, May 8, 2014 at 5:00 PM, Tyler Nowicki <tnowicki at apple.com> wrote:
> Hi,
>
> It doesn't really require a spelling because it's not something that
> the user can type out directly. If you went with two attributes
> instead of one, then you don't require a spelling for it. You could
> get away with something like:
>
> def LoopHint : Attr {
>  let Args = [IntArgument<"type">,
>                  ExprArgument<"value", 1>];
> let AdditionalMembers = [{
>    // Your static methods
>  }];
> }
>
> def VectorizeLoopHint : LoopHint;
> def InterleaveLoopHint : LoopHint;
>
> Pretty sure that would work for you. You definitely do not need a
> spelling to get the class generated by tablegen (there are several
> other attributes which are implicit-only and have no spelling).
>
>
> Something may be missing here. It fails to compile the td file:
>
> Basic/Attr.td:1763:25: error: Couldn't find class 'LoopHint'
> def VectorizeLoopHint : LoopHint;

Ah, yes, because LoopHint needs to be a class, not a def. But once you
make it a class, we don't generate C++ code for it directly.

>
> Changing def LoopHint for class LoopHint also fails
>
> Basic/Attr.td:1763:1: error: Record `InterleaveLoopHint', field `Spellings'
> does not have a list initializer!
> def InterleaveLoopHint : LoopHint;
>
> Adding an empty spelling `let Spellings = []’ allows it to get through the
> td file but it does not generate a LoopHint class causing the compilation of
> the generated code to fail.

Yup, exactly!

>
> AST/Attrs.inc:2500:39: error: expected class
>       name
> class InterleaveLoopHintAttr : public LoopHint {
>
> Perhaps I’m doing something wrong? But…

Nope, this is what I get for answering without trying first. ;-)

>
> The pretty printing function is generated to blank anyway without a Spelling
> because the spelling is required by tablegen to generate the body of the
> function.
>
> static void
> writePrettyPrintFunction(Record &R,
>                          const std::vector<std::unique_ptr<Argument>> &Args,
>                          raw_ostream &OS) {
>   std::vector<FlattenedSpelling> Spellings = GetFlattenedSpellings(R);
>
>   OS << "void " << R.getName() << "Attr::printPretty("
>     << "raw_ostream &OS, const PrintingPolicy &Policy) const {\n";
>
>   if (Spellings.empty()) {
>     OS << "}\n\n";
>     return;
>   }
> …
>
> 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?

>  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.

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