[LLVMdev] Vectorization: Next Steps

Chris Lattner clattner at apple.com
Mon Feb 13 21:06:15 PST 2012

On Feb 13, 2012, at 3:30 PM, Hal Finkel wrote:

>>> This makes sense. What do you think will be the best way of
>>> synchronizing things like CPU subfeatures between this API and the
>>> backend target libraries? They could be linked directly, although I
>>> don't know if we want to do that. tablegen could extract a bunch of this
>>> information into separate objects that get linked into opt.
>> The best model we have at the moment is TargetLoweringInfo, as used by LoopStrengthReduction.  The details of this interface aren't a great example to follow for a few reasons (i.e. it has selectiondag specific stuff in it, which is a layering violation) but the idea is sound.  This does mean that running "opt -vectorize foo.bc" would not get the same optimization as running clang with the target you want enabled though.  We already have this problem with -loop-reduce though.
> LoopStrengthReduction is currently created in
> TargetPassConfig::addIRPasses (CodeGen/Passes.cpp). Currently the
> vectorization pass is created in
> PassManagerBuilder::populateModulePassManager (which is used by opt).
> Are you suggesting that I move the vectorization pass creation into
> CodeGen? Or are you saying that TLI will sometimes be available to the
> pass, as it is now, when called from a full-compilation driver (like
> clang)? Or are you suggesting that I propose some object like TLI that
> might be available in 'opt' even though TLI itself is not available
> there?

I'm suggesting that BBVectorize stay wherever it is (I still haven't looked at it, sorry) and that it use getAnalysis<TargetVectorInfo>().  When run from opt on the command line, it would use the default constructed implementation of TargetVectorInfo (just like "opt -loop-reduce" does).  However, when run by clang, a target-specific TargetVectorInfo subclass would be added to the pass pipeline first if it is available.


More information about the llvm-dev mailing list