<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 5:14 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 5:04 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>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>
</blockquote><div><br></div><div><snip></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></div></blockquote></div><br>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.</div></div></blockquote><br></div><div>It might nice if scalaropts did not need to link against libTarget—we could easily avoid introducing more dependence on libTarget if that’s a goal.</div><div><br></div><div>Either way, we need an IR-level API that requires subtarget initialization. It should be explicit which passes do and don’t require the subtarget. This would add *a lot* of clarity to the role of CodeGenPrepare-style IR passes which is starting to become very murky. It would separate the problem of providing TargetMachine to IR passes from the problem of initializing the PassManager. The distinction between opt and llc passes has already become meaningless.</div><div><br></div><div>Back to this..</div><div><br></div><div><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote"><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></blockquote></div><div><div class="gmail_extra"><br></div></div><div class="gmail_extra">Yes, they could be abstract interfaces, but no, they wouldn’t have trivial implementations. TargetContext could be wrapped with trivial implementations as a separate interface purely as a convenience for passes that use TargetContext “only if available” (effectively the current TTI). I would not want a wrapper for SubtargetContext.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">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.</div></div></blockquote><div><div dir="ltr"><div class="gmail_extra"><br></div></div></div></div><div class="gmail_extra">The design problem we have today is that TTI and TargetMachine are broken in the presence of function attributes. And IR passes are using both TTI and TargetMachine directly. My first suggestion was a straightforward fix, but builds more layers of complexity:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><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><font face="Menlo"><br></font></div><div><font face="Menlo">(IR passes that use TargetMachine directly would need to be fixed to use CGContext).</font></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I like Dan’s suggestion of using LLVMContext as the container instead, but we have to think about how that fits with existing TTI—when should a pass use one or the other? I suggest that passes that use target info *if available* continue using TTI while lowering passes directly use CG/SubtargetContext.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I’m not aware that what I’ve suggested contradicts any previous discussions. There have been lengthy discussions on whether we should extend LLVM IR to support more lowering in IR passes. I agree with Chris and others that we should *not* extend LLVM IR to support lowering. That’s a separate issue.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Andy</div></body></html>