RFC: Enable vectorization of call instructions in the loop vectorizer

Eric Christopher echristo at gmail.com
Thu Mar 5 10:09:29 PST 2015

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.



> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150305/a93ff6d5/attachment.html>

More information about the llvm-commits mailing list