Question on Criteria for Acceptable IR in RemoveDeadValuesPass

MLIR
1

Hello LLVM Community,

I’m currently exploring the RemoveDeadValuesPass implemented in RemoveDeadValues.cpp within MLIR and have some questions regarding the criteria used for determining an acceptable IR for dead values removal.

The main function, runOnOperation(), employs a specific check for acceptable IR before it proceeds to remove dead values. This involves ensuring the IR does not contain operations that are classified under the branch op interface, symbol op interface, or symbol user op interface, among others.

However, I’ve observed a scenario that prompts a deeper inquiry: if a moduleOp contains a memref.global private constant op, such as a Memref initialized with four integer values (i.e memref.global "private" constant @__constant_4xi32 : memref<4xi32> = dense<[0, 16, 32, 48]> {alignment = 16 : i64}, it seems to categorize the IR as unacceptable for this pass. This specific inclusion of memref.global private constant op piqued my interest, and I would appreciate an explanation on why such a global operation disqualifies the IR from dead values removal.

CC: @SrishtiSrivastava @Wheest

Thank you for your insights!
Zeeshan Siddiqui

2

It’s also an issue I’ve encountered, specifically when converting StableHLO models to linalg, which inserts names constants.

This causes an issue for me when lowering, since at one point they end up being dead, and they can’t be removed.

I guess a rationale for it could be “that which has a name should be handled more carefully, and not removed unless specifically requested.”

But personally that’s not intuitive to me, and does inconvenience me. I’ve not got around to making a patch yet.

If there are other good reasons for this behaviour, a compromise could be adding a flag to the pass to allow named values to be handled?

3

I have submitted the change to remove the limitation:

let’s see how it goes, thank you!