Adding utility/debugging passes upstream

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.

Thanks,
Anna

I think you should start by describing exactly what the pass is doing and how it is useful for working with/on RewriteStatepointsForGC.

If it is correctly tested and documented, I don’t see why it couldn’t be in-tree.

Hi Mehdi,

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

If it is correctly tested and documented, I don’t see why it couldn’t be in-tree.

Yes, agreed.


Mehdi

Thanks,
Anna

Hey Anna,

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

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

Thanks,
Anna

I'll raise my hand as enthusiastically positive about adding
utility/debugging passes. The whole point of LLVM is to act as a
shared infrastructure - if there are passes for debugging/analysis
that help you and they may be generally useful to others, I think
there's great benefit in pushing them upstream.

Best,

Alex