[llvm] r210641 - Create macro INITIALIZE_TM_PASS.

[Chandler Carruth]

On Wed, Jun 11, 2014 at 7:17 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 11 June 2014 14:00, Quentin Colombet <qcolombet at apple.com> wrote:
> > I think this needs more discussion.
> >
> > I have proposed something similar back in January and we agreed it was
> not a
> > good idea to expose such interface:
> >
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140113/201619.html
> >
> > The bottom line is, this situation is supposed to be the exception and
> we do
> > not want to provide support for it. The rational is that using target
> > interface, you may violate the layer of LLVM, i.e., you may create a
> > libraries dependencies.
>
> Thanks for the pointer.
>
> If I understand it correctly, the objection is not so much to the
> macro, but to spreading the use of TM in IR passes.
>
> Andrew, given what GlobalMerge is doing, do you think it should be
> rewritten to use TTI?
>
> The macro would still be used in AtomicExpandLoadLinkedPass and
> CodeGenPrepare. IMHO it actually makes it easier to spot the llvm
> passes that are using TM.


I think we're mixing concepts up here. Sorry I didn't jump on the earlier
review thread.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140611/90ba8ffd/attachment.html>