[LLVMdev] Vectorization: Next Steps
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
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