[PATCH] #pragma vectorize

[Hal Finkel]

Tyler,

Thanks!

+    PP.Diag(Tok.getLocation(), diag::err_expected) <<

+      "vectorize, or interleave";

+    return;

Remove the comma before the "or".

+      PP.Diag(Tok.getLocation(), diag::err_expected) <<

+      "vectorize, or interleave";

+      return;

Same here.
(and several other places)

+    // Read optimization option identifier

Please make comments complete sentences where practical.

And, most importantly, this needs a documentation update!

 -Hal

----- Original Message -----
> From: "Tyler Nowicki" <tnowicki at apple.com>
> To: "Hal J. Finkel" <hfinkel at anl.gov>, "Chandler Carruth" <chandlerc at gmail.com>
> Cc: "Alexey Bataev" <alexey.bataev at intel.com>, "Nadav Rotem" <nrotem at apple.com>, "llvm cfe" <cfe-commits at cs.uiuc.edu>
> Sent: Tuesday, April 22, 2014 6:54:27 PM
> Subject: Re: [PATCH] #pragma vectorize
> 
> 
> 
> Please review this updated patch. It includes the changes we
> discussed. Thanks for all your input!
> 
> 
> Tyler
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Apr 22, 2014, at 2:30 PM, Tyler Nowicki < tnowicki at apple.com >
> wrote:
> 
> 
> 
> 
> 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
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory