[llvm] r210641 - Create macro INITIALIZE_TM_PASS.
liujiangning1 at gmail.com
Fri Jun 13 02:54:53 PDT 2014
OK. I will give follow-up soon.
Is there be any objection if I move GlobalMerge pass to CodeGen?
2014-06-12 3:03 GMT+08:00 Rafael Espíndola <rafael.espindola at gmail.com>:
> > 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
> > accept a TargetMachine. We can still have plenty of IR-operating passes
> > 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
> > 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
> > But there are plenty of passes which really aren't that target
> > 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
> > with it enough to really tell whether it should instead be reduced to
> use a
> > easily abstracted interface like TargetTransformInfo.
> OK, that makes sense.
> Jiangning, can you move the macro to some header in
> include/llvm/CodeGen and figure out if GlobalMerge.cpp should move to
> lib/CodeGen or be implemented on top of TargetTransformInfo?
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits