[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: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Chandler Carruth" <chandlerc at google.com>, "Jim Grosbach" <grosbach at apple.com>, "Eric Christopher"
> <echristo at gmail.com>, "Owen Anderson" <resistor at mac.com>, "llvm-commits at cs.uiuc.edu LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Tuesday, October 9, 2012 11:41:55 PM
> Subject: Re: [patch] "TargetTransform" as an API between codegen and IR-level passes
> 
> 
> 
> On Oct 9, 2012, at 9:09 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> > ----- 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:
> > 
> 
> 
> Hi Hal!
> 
> Thanks for looking at this.
> 
> > - Should we put ScalarTargetTransformInfo and
> > VectorTargetTransformInfo in separate headers?
> > 
> 
> I think that it is a good idea to move them to separate files when
> they get bigger.

If you don't mind, I'd prefer to move them info separate files "now" (meaning in the near future). The vectorization interface will be experimental for some time, and when I change it, I don't want to have to recompile a bunch of unrelated code (like LSR).

> 
> > - Should they have a common base class? isTypeLegal will certainly
> > be common to both.
> 
> Maybe, I am not sure.  It may be difficult to create a meaningful
> hierarchy as we add more new interfaces. I suggest that we wait and
> see which functions are added, and refactor if needed.
> Another option is to let the IR-level passes use a number of
> instances at one. For example, the BB-vectorizer would ask the
> ScalarTTI  "isTypeLegal", and VectorTTI about other things.

Fair enough.

> 
> > 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?
> 
> Lets wait for this patch to go in, and start a new thread on
> LLVM-dev. I look forward to discussing the details but I also want
> to make sure that we get the abstraction right before we move on to
> the next step.

Okay. Sounds good.

Thanks again,
Hal

>   
> > 
> > -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
> 
> 

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