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

[Nadav Rotem]

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.

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

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