[llvm-commits] [patch] "TargetTransform" as an API between codegen and IR-level passes

[Hal Finkel]

----- Original Message -----
> From: "Nadav Rotem" <nrotem at apple.com>
> To: "llvm-commits at cs.uiuc.edu LLVM" <llvm-commits at cs.uiuc.edu>
> Cc: "Chandler Carruth" <chandlerc at google.com>, "Hal Finkel" <hfinkel at anl.gov>, "Jim Grosbach" <grosbach at apple.com>,
> "Eric Christopher" <echristo at gmail.com>, "Owen Anderson" <resistor at mac.com>
> Sent: Tuesday, October 9, 2012 6:37:00 PM
> Subject: [patch] "TargetTransform" as an API between codegen and IR-level passes
> 
> Hi,
> 
> Following the discussion that we had on the mailing list and on IRC I
> implemented an abstraction layer to separate IR-level passes from
> the codegen. Passes such as Loop-Strength-Reduce rely on the CodeGen
> for querying target-specific information (such as the legality of
> types).  In the future we plan to add new passes (vectorizer!!)
> which will rely heavily on target-specific information.  So, before
> things get out of hand, we agreed that we need to define an
> interface. The idea is that IR-level transformations that live in
> /Transforms/ must not include files from /Target. We also don't want
> to create one mega analysis that will expose everything in the
> codegen.  Following Evan's suggestion, I created a number of classes
> that can provide different codegen specific information. Every class
> provides information for a different set of optimizations. Currently
> only one interface is implemented and I ported LSR and LowerInvoke
> to use it.
> 
> Here's the general design.  We have a new Analysis pass called
> "TargetTransformInfo". Much like DataLayout (until
> recentlyTargetData), it exists in the pass manager and can be
> obtained using getAnalysisIfAvailable call.  This analysis can
> provide a number of classes. Currently there are two interfaces:
> ScalarTransformInfo, which is used by scalar transformation such as
> LSR and LowerInvoke,  and VectorTransformInfo, which is currently
> empty, and will be used by the vectorizers. The XXXTransformInfo
> classes are abstract classes which are implemented by concrete
> codegen classes. When the TargetMachine is initialized it creates
> the concrete XXXTargetTransformImpl classes and add creates the
> TargetTransformInfo analysis pass. Notice that the interface that
> the XXXinfo classes exposes is IR-level interface.

Thanks for working on this, this is great! A few comments:

 - Should we put ScalarTargetTransformInfo and VectorTargetTransformInfo in separate headers?

 - Should they have a common base class? isTypeLegal will certainly be common to both.

Also, as a start for the vectorization interface, BBVectorize would most naturally want something like this:

// Returns true if the target efficiently supports a vectorized form of Inst which operates on vectors of
// N x (scalar type of Inst). For instructions, like a vector shuffle, for which the return type may have a
// different number of vector elements from the arguments, NR specifies the number of vector elements of the
// return type. 
virtual bool isVectorizedInstLegal(Instruction *Inst, unsigned N, unsigned NR = 0);

BBVectorize will also want relative cost information at some point, but the above seems to be the most pressing need. What do you think?

 -Hal

> 
> This patch includes the following changes, broken into three patches.
> :
> 
> 1. The new TargetTransform classes (TargetTransform_Infra.diff)
> 2. Changes to LSR and LowerInvoke to use this new infrastructure and
> break the dependency on TLI (TargetTransform_Passes.diff).
> 3. Changes to the command line tools OPT and LLC.  Opt now links with
> the codegen (TargetTransform_tools.diff).
> 
> 
> 
> 
> Thanks,
> Nadav
> 
> Here is a small diagram of the different components:
> 
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory