<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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 class="gmail_extra"><br></div><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 class="gmail_extra"><br></div><div class="gmail_extra"><br></div><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 class="gmail_extra"><br></div><div class="gmail_extra">-Chandler</div></div>