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). 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. 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. -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131205/b3f3006f/attachment.html>
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>
On Thu, Dec 5, 2013 at 5:04 PM, Andrew Trick <atrick at apple.com> wrote:> 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. ><snip>> > 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). >This sounds like you want IR-level passes which have direct, hard dependencies on the target and codegen. That would be a radical departure from the core design of the IR / MI separation. We have discussed this directly in the past and Chris and others have argued *very strongly* against this. If you want to reverse this design direction, it really should be a totally separate discussion from the current discussion. I'm not actually in the "strongly against" camp on this subject, but I *am* strongly against trying to design CGContext to address these needs when we don't yet have either a concrete design or agreement on that design. I think we should restrain our design considerations to what we need to solve the limited problem we have today, and not *breaking* the existing design around TTI, and the IR/Target layering we currently use. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131205/c368f207/attachment.html>
On 12/5/13 4:47 PM, Chandler Carruth wrote:> > 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.I just want to second this. There are a number of folks out there interested in target or sub-target independent optimization uses for at least part of their compilation pipeline. I'm one of them. :) p.s. Sorry for chiming in so late. Philip