[LLVMdev] [RFC] CGContext skeleton implementation

[Andrew Trick]

On Dec 5, 2013, at 4:47 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Thu, Dec 5, 2013 at 4:16 PM, Andrew Trick <atrick at apple.com> wrote:
> We currently have something that looks like:
> 
> IR Transform
> (links with)   -> TargetTransformInfo
> (dynamic call) -> X86TTI
> (links with)   -> X86Subtarget
> 
> I was thinking of directly replacing X86Subtarget as such:
> 
> IR Transform
> (links with)   -> TargetTransformInfo
> (dynamic call) -> X86TTI
> (links with)   -> TargetMachine
> (provides)     -> CGContext
> 
> So CGContext could still live inside libTarget. CGContext would be
> initialized for a Function based on the attributes and the information already in its container, TargetMachine.
> 
> It sounds like you would be making CGContext part of libCore instead, like this:
> 
> IR Transform
> (links with)   -> LLVMContext
> (provides)     -> CGContext
> 
> CGContext would still need to be initialized with a TargetMachine, which could happen whenever the TargetMachine and Function are both available.
> 
> I'm fine with that as long as
> - no one objects to putting CGContext in libCore
> - our goal is to eventually replace TargetTransformInfo with CGContext (maybe renamed)
> 
> I think the issue here is whether we want to continue use an AnalysisGroup to vend target info, or rather to have passes get what they need from LLVMContext. I find the AnalysisGroup thing too subtle and prone to driver bugs, but haven't fully worked out an alternate design.
> 
> I'm not actually a fan of the analysis group hack, and there are better ways to slice this, but I don't really like the direction of putting the CGContext into the LLVMContext.
> 
> There are still very viable uses of LLVM which have *no* concept of a target outside of the LLVM IR itself. I think we should preserve this abstraction boundary. I think that means there needs to be an *abstract* interface between the IR layer and the target/codegen layer with a dynamic call across that boundary.
> 
> So this makes sense to me:
> 
> LLVMContext
>   -> TargetContext (initialized when TargetMachine is available)
>     -> SubtargetContext (initialized when Function attributes are available)
> 
> Only if TargetContext and SubtargetContext are abstract interfaces with trivial implementations available for cases where there is no target (in the libTarget sense).

Right. On the flip side, some passes should be able to make hard queries against target/subtarget that fail if the driver doesn’t initialize them. I don’t want any way to accidentally run the vectorizer or LSR without initializing my subtarget info. Also, I want to prevent early passes from getting at subtarget info.

> I don't really think that's what you're aiming for, so I would advocate for the MachineModuleInfo or the TargetMachine being the provider of the CGContext or the TargetContext and SubtargetContext. I like the TargetMachine providing it personally, but I don't feel strongly here. I also think that we could start with the MachineModuleInfo providing it and refactor that in a subsequent patch.

The only thing I don’t like about introducing CGContext in MachineModuleInfo is that TargetTransformInfo is still clearly doing the wrong thing. We would be falsely advertising that we fixed something that’s still broken.

> FWIW, I have a plan to remove the crazy analysis group stuff in the new pass manager. My hope is that we have a simple analysis which can be configured with dynamic calls into a TargetMachine (or some TargetMachine-wrapping interface). It will be very explicit with none of the analysis group magic. It will just preserve the dynamic interface boundary between the the IR layer and the target layer.

In that case it sounds like we could have:

TargetTransformInfo analysis for passes that can benefit from target heuristics when available but happen to do something reasonable when the target is missing (inlining). Hopefully (please!) avoid dependence on subtarget here.

Passes that depend on TargetMachine can use CGContext for hard target and subtarget info queries. Since they must depend on TargetMachine anyway, they can do something like TM.getCGContext(Function).

-Andy 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131205/80110f17/attachment.html>