<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 5, 2013, at 4:47 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 5, 2013 at 4:16 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>We currently have something that looks like:</div><div><br></div><div><font face="Menlo">IR Transform</font></div>
<div><font face="Menlo">(links with) -> TargetTransformInfo</font></div><div><font face="Menlo">(dynamic call) -> X86TTI</font></div><div><font face="Menlo">(links with) -> X86Subtarget</font></div><div><br></div>
<div>I was thinking of directly replacing X86Subtarget as such:</div><div><br></div><div><font face="Menlo">IR Transform</font></div><div><font face="Menlo">(links with) -> TargetTransformInfo</font></div><div><font face="Menlo">(dynamic call) -> X86TTI</font></div>
<div><font face="Menlo">(links with) -> TargetMachine</font></div><div><font face="Menlo">(provides) -> CGContext</font></div><div><br></div><div>So CGContext could still live inside libTarget. CGContext would be</div>
<div>initialized for a Function based on the attributes and the information already in its container, TargetMachine.</div><div><br></div><div>It sounds like you would be making CGContext part of libCore instead, like this:</div>
<div><br></div><div><font face="Menlo">IR Transform</font></div><div><font face="Menlo">(links with) -> LLVMContext</font></div><div><font face="Menlo">(provides) -> CGContext</font></div><div><br></div><div>CGContext would still need to be initialized with a TargetMachine, which could happen whenever the TargetMachine and Function are both available.</div>
<div><br></div><div>I'm fine with that as long as</div><div>- no one objects to putting CGContext in libCore</div><div>- our goal is to eventually replace TargetTransformInfo with CGContext (maybe renamed)</div><div><br>
</div><div>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.</div>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>So this makes sense to me:</div><div><br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div>LLVMContext<br></div><div> -> TargetContext (initialized when TargetMachine is available)</div>
<div> -> SubtargetContext (initialized when Function attributes are available)</div><div class="im"><div></div></div></blockquote></div><br>Only if TargetContext and SubtargetContext are abstract interfaces with trivial implementations available for cases where there is no target (in the libTarget sense).</div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra">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.</div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra">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.</div>
</div></blockquote><br></div><div>In that case it sounds like we could have:</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>-Andy </div><br></body></html>