[llvm] [DebugInfo][InstCombine] When replacing bswap idiom, add DebugLoc to new insts (PR #114231)
David Blaikie via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 5 11:20:38 PST 2024
dwblaikie wrote:
> Right, I think a slightly more detailed form of the policy I'd suggest would be that every original instruction whose outputs/side-effects are produced by the new instructions is interesting, and the location for the new instructions should be the merge of all interesting instructions. So for example,
>
> * In most peephole optimizations, we would only use the final instruction's location, because that is the only instruction that the new instructions are reproducing.
> * When we hoist and merge equivalent instructions from both sides of a branch, the new instruction is reproducing both of the original instructions, so we'd use a merged location.
> * If we merged two adds into a single vector add, the vector add would use a merged location because it's defining the combined value of the original adds.
>
> I'm not sure about using other instructions as fallbacks if the sole interesting instruction has a missing location; it seems like it might help salvage _some_ information where we would otherwise have none, I'd just want to be sure there aren't cases where it would be misleading.
Sounds good to me. (re: merging two adds - for a sec I was confused, I thought you were describing (a + (b + c)) - in which case it sounded more like the peephole description, but you meant merging ((a1 + b1), (a2 + b2)) into ((a1, a2) + (b1, b2)) ? Yeah, that looks like the function call merging, the instruction is producing the results of both the original instructions)
https://github.com/llvm/llvm-project/pull/114231
More information about the llvm-commits
mailing list