[PATCH] D114766: If constrained intrinsic is replaced, remove its side effect

Kevin P. Neal via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 1 10:04:06 PST 2021


kpn added a comment.

In D114766#3161426 <https://reviews.llvm.org/D114766#3161426>, @nikic wrote:

> Marking as changes requested per above comment -- really don't think this is the right place to address this, since it will just create an incorrect picture of what LLVM can optimize in practice. Usually, this fold will happen via InstCombine rather than InstSimplifyPass. But I don't think changing InstCombine is the right solution either, as any number of passes do this kind of "simplify and DCE" pattern.

Let's back up. If we try and move logic into wouldInstructionBeTriviallyDead() then what would that look like? Transform and analysis passes both have loads of information that is not available to wouldInstructionBeTriviallyDead(). Trying to gather that information again would be non-trivial and wouldn't scale since it would be a layering violation if wouldInstructionBeTriviallyDead() tried to gather it. So information about whether or not a constrained intrinsic can be eliminated would need to be passed into wouldInstructionBeTriviallyDead(). And we'll have to go pass by pass implementing this passing around of information. What would or should that look like?

Let me float this idea: Would a bool passed in as an argument be sufficient? As in "I, an arbitrary transform pass, think this instruction is dead, but what does wouldInstructionBeTriviallyDead() say about it?"

@nikic, @lebedev.ri: Is there another approach that makes more sense?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114766/new/

https://reviews.llvm.org/D114766



More information about the llvm-commits mailing list