<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 5, 2013 at 7:36 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>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>
</blockquote><div><br></div><div>We already have that state today in the overwhelming majority of the cases. The pass manager built by the PassManagerBuilder doesn't need a target at all. Yes, there is CodeGenPrepare which violates all manner of rules, but thus far it has been viewed as a hack, and something that should go away because, at a very fundamental level, it *is* a lowering pass.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Either way, we need an IR-level API that requires subtarget initialization.</div></blockquote><div><br>
</div><div>Why? The only concrete use case I can come up with is lowering, but you claim that you aren't trying to do lowering in the IR -- If you can't make reasonable decisions without a concrete subtarget, then I claim you *are* lowering. This is why I suggested that this would be a very significant change in design from the direction that LLVM is currently moving.</div>
<div><br></div><div><br></div><div>I can see the need for target *heuristics* in an optimization pass (not necessarily canonicalization) that is not doing lowering. But by definition of being heuristics, there is an obvious way to implement and test them in a target independent manner. When the target information is no longer a heuristic and cannot be stubbed out in a target independent manner, I claim that the transformation it is guiding has ceased to be target independent as well and doesn't belong in the IR.</div>
<div><br></div><div><br></div><div>But all of this should absolutely be discussed in a separate thread (or in person) as it is largely orthogonal to allowing the TargetMachine to react appropriately to function attributes.</div>
</div></div></div>