[LLVMdev] [llvm-commits] [patch] "TargetTransform" as an API between codegen and IR-level passes
evan.cheng at apple.com
Tue Oct 9 17:54:44 PDT 2012
Ah, I was confused. I forgot they are used by LowerInvoke. I just want to make sure functions that are in TargetLowering which are only used in codegen are not moved to ScalarTargetTransformInfo.
On Oct 9, 2012, at 5:50 PM, Nadav Rotem <nrotem at apple.com> wrote:
> The functions that I placed in ScalarTargetTransformInfo are functions what were used by LSR and LowerInvoke. getJumpSize and getJumpAlignment are used by LowerInvoke. Do you suggest that I remove them from TargetLowering and keep them in ScalarTargetTransformInfo ?
> On Oct 9, 2012, at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>> Hi Nadav,
>> The concept and the patch both look good to me. One question about ScalarTargetTransformInfo. Right now it contains hooks like getJumpBufSize(). I don't believe this would ever need to be exposed to IR-level passes. Should they be left in TargetLowering?
>> On Oct 9, 2012, at 4:37 PM, Nadav Rotem <nrotem at apple.com> wrote:
>>> 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.
>>> 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).
>>> Here is a small diagram of the different components:
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
More information about the llvm-dev