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

[Jim Ingham via lldb-commits]

> On Feb 10, 2016, at 3:45 AM, Luke Drummond <luke.drummond at codeplay.com> wrote:
> 
> 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.

Yes, that seems reasonable.

> 
>> 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.
> 

Did you file bugs with llvm on these issues?  It would be good to file a "move to the new pass manager when ready" bug on lldb, but it should be blocked on the relevant llvm bugs.

Jim

> 
> http://reviews.llvm.org/D17027
> 
> 
>