[llvm-dev] Adding utility/debugging passes upstream

[Anna Thomas via llvm-dev]

I’m interpreting this as neutral/no objections to committing in-tree :)

If thats the case, we’ll continue the review on llvm-commits itself, and check-in code upstream.

Thanks,
Anna

On Sep 30, 2016, at 6:55 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote:

Hey Anna,

On Sep 30, 2016, at 2:46 PM, Anna Thomas <anna at azul.com<mailto:anna at azul.com>> wrote:

Hi Mehdi,

On Sep 30, 2016, at 4:27 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote:


On Sep 30, 2016, at 12:37 PM, Anna Thomas via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

Hi,

I was wondering what’s the community guideline for adding new passes which are solely used for debugging/analysis purposes? Can this be in the upstream llvm, or such passes are more suitable in local downstream repository?

In our case, the ‘utility (ease-of-analysis)’ pass is for transformation done by RewriteStatepointsForGC (RS4GC). Note that right now, RS4GC is not enabled in the opt pipeline upstream, but the utility pass would be for downstream users who have RS4GC enabled in their opt pipeline.

I think you should start by describing exactly what the pass is doing and how it is useful for working with/on RewriteStatepointsForGC.
The pass will remove all the gc.relocates that are inserted by RewriteStatepoints. This is solely useful for analysis purposes of the final optimized IR (with RS4GC in place), when the IR is too polluted with gc.relocates of the original pointers.

More details at: https://reviews.llvm.org/D25096

The scenario where this is useful: There is a performance regression and analyzing through the final IR is too tedious because of all the gc.relocates.
This pass would take the optimized IR, and remove the gc.relocates. This will enable easier manual traversal through IR (without having to worry about the gc.relocates).

This seems fine to me to be in-tree on the principle.

But let’s hear about others…


—
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161006/6eb8498d/attachment-0001.html>