[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