RFC: Enable vectorization of call instructions in the loop vectorizer

[Hal Finkel]

Hi Michael,

First, the Clang changes should be separated out and sent to cfe-commits for review. Also, I think that I'd still rather add the functions to TLI inside of TLI. I like the idea that the frontend can add others, and we should keep that capability. However, there is no reason that other frontends should not be able to take advantage of this knowledge. We should translate the Clang-level CodeGenOpt into LLVM-level CodeGenOpts, and then add these there.

+  if (Args.hasArg(options::OPT_fveclib)) {

+    if (Arg *A = Args.getLastArg(options::OPT_fveclib)) {

+      StringRef v = A->getValue();

+      CmdArgs.push_back(Args.MakeArgString("-fveclib=" + v));

+    }

+  }

You don't need the outer if here.

Furthermore, I think that this whole thing can be replaced by:

  Args.AddLastArg(CmdArgs, options::OPT_fveclib);

 -Hal

----- Original Message -----
> From: "Michael Zolotukhin" <mzolotukhin at apple.com>
> To: "Eric Christopher" <echristo at gmail.com>
> Cc: "Arnold Schwaighofer" <aschwaighofer at apple.com>, "Hal J. Finkel" <hfinkel at anl.gov>, "Commit Messages and Patches
> for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Thursday, March 5, 2015 5:11:00 PM
> Subject: Re: RFC: Enable vectorization of call instructions in the loop vectorizer
> 
> 
> Hi Eric, Hal, Arnold,
> 
> 
> Could you please take a look at this patch then (in the original
> series it’ll replace 0006-patch)?
> 
> 
> I’m totally unfamiliar with clang options passing and parsing, so I’d
> appreciate any corrections here. E.g. I chose ‘f_Group’ for the
> option almost at random:)
> 
> 
> Thanks,
> Michael
> 
> 
> 
> 
> 
> 
> 
> On Mar 5, 2015, at 10:09 AM, Eric Christopher < echristo at gmail.com >
> wrote:
> 
> 
> 
> 
> 
> On Thu, Mar 5, 2015 at 9:02 AM < aschwaighofer at apple.com > wrote:
> 
> 
> 
> 
> On 03/05/15, Hal Finkel wrote:
> > Okay, unfortunately, this specifically does not work for me. I need
> > to control the triple used for compilation in cross-compiling
> > environments, and whether or not calls to some particular library
> > might be generated does not belong there.
> > 
> > Currently, TLI is constructed by the frontend like this (to copy
> > from Clang):
> > 
> > // Figure out TargetLibraryInfo.
> > Triple TargetTriple(TheModule-> getTargetTriple());
> > PMBuilder.LibraryInfo = createTLI(TargetTriple, CodeGenOpts);
> > 
> > and this information needs to be passed in from the frontend (so
> > that it can be easily controlled using frontend command-line
> > flags). We should define some enum with the different library
> > types being targeted, and probably stick that into CodeGenOpts,
> > and use it in TLI as appropriate. The backend might also generate
> > calls into such a library, so CodeGenOpts is really the right
> > place for this.
> 
> Works for me.
> 
> 
> I viewed using the environment as a stringly typed version of what
> you suggest until we have some real users of this. I must admit I
> have not researched deeply into whether the frontend could have set
> the triple in TheModule->getTargetTriple() from " "x86-apple-darwin”
> to "x86-apple-darwin-accelerate".
> 
> 
> 
> 
> FWIW you can do this, but ... let's not :)
> 
> 
> CodeGenOpts is how you pass this sort of stuff down.
> 
> 
> Thanks!
> 
> 
> -eric
> 
> 
> 
> That said this would have been a hack in the frontend and using a
> enum or alternatively just setting the set of functions in the
> frontend is cleaner.
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CFE-Add-fveclib-option.patch
Type: text/x-patch
Size: 4791 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150305/556af3c5/attachment.bin>