[Lldb-commits] [PATCH] D17027: [expression evaluator] Allow runtimes to execute custom LLVM ModulePasses over the generated IR at various stages after expression compilation.

Luke Drummond via lldb-commits lldb-commits at lists.llvm.org
Wed Feb 10 03:45:47 PST 2016


ldrumm added a comment.



In http://reviews.llvm.org/D17027#347487, @jingham wrote:

> This seems fine as a generic instrumentation point.  Obviously, the onus in on the passes, since they could totally ruin the expression evaluation if they don't do their job right...  But I'm not sure there's any good way to make this not a sharp tool.  But you should wait on Sean to weigh in as well...


I appreciate this, and I think that if a runtime provides passes, the expectation should be that the runtime knows what it's doing because this really //is// a powertool - as you say. I think it's a generally useful mechanism for better modularity/encapsulation of language-specific behaviours that are required during expression evaluation. For example, there are presently a large number of language-specific fixups in the clang-based expression evaluator, that could be factored out into individual `EarlyPasses/LatePasses` provided by their runtime, leaving `IRForTarget` and friends a lot cleaner and more maintainable.

> One question, what is the force of the "legacy" in "llvm::legacy::PassManager?  Is there some more "modern" way to do this, is this going to go away at some point?


The legacy pass manager is fully functional and tested. Using the new version does not work unfortunately in this instance. We can certainly move to the new version as it matures and becomes ready for general use, but I tried this implementation with both `llvm::PassManager` and the the `llvm::legacy::PassManager`, and unfortunately the new PassManager did not work here.


http://reviews.llvm.org/D17027





More information about the lldb-commits mailing list