<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 11, 2014 at 7:17 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 11 June 2014 14:00, Quentin Colombet <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a>> wrote:<br>

> I think this needs more discussion.<br>
><br>
> I have proposed something similar back in January and we agreed it was not a<br>
> good idea to expose such interface:<br>
> <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140113/201619.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140113/201619.html</a><br>
><br>
> The bottom line is, this situation is supposed to be the exception and we do<br>
> not want to provide support for it. The rational is that using target<br>
> interface, you may violate the layer of LLVM, i.e., you may create a<br>
> libraries dependencies.<br>
<br>
</div>Thanks for the pointer.<br>
<br>
If I understand it correctly, the objection is not so much to the<br>
macro, but to spreading the use of TM in IR passes.<br>
<br>
Andrew, given what GlobalMerge is doing, do you think it should be<br>
rewritten to use TTI?<br>
<br>
The macro would still be used in AtomicExpandLoadLinkedPass and<br>
CodeGenPrepare. IMHO it actually makes it easier to spot the llvm<br>
passes that are using TM.</blockquote><div><br></div><div>I think we're mixing concepts up here. Sorry I didn't jump on the earlier review thread.</div><div><br></div><div>The key is that we *really must not* add more passes to lib/Transforms which accept a TargetMachine. We can still have plenty of IR-operating passes in lib/CodeGen that take a TargetMachine, that's fine. If you want to have a macro to automate it, put it in include/llvm/CodeGen/CodeGenPassSupport.h or some other *clearly* backend header file so that it is really obvious that it should not be used in purportedly target-independent passes.</div>
<div><br></div><div>TargetTransformInfo is a generic interface by which a target can expose information to a lib/Transform pass. This allows truly target independent passes to be tested without even having a target around because the interface they use to communicate with the target is very nicely abstracted. But there are plenty of passes which really aren't that target independent, and those should just stay in lib/CodeGen.</div>
<div><br></div><div>AFAIK, CodeGenPrep is the only pass that violates these principles today. I think it should just be moved to lib/CodeGen personally, but haven't worked with it enough to really tell whether it should instead be reduced to use a easily abstracted interface like TargetTransformInfo. </div>
</div></div></div>