[llvm] [WebAssembly] Fold unsigned offset (PR #145829)

[Derek Schuff via llvm-commits]

================
@@ -66,18 +66,18 @@ try.cont:                                         ; preds = %entry, %catch.start
 
 ; CHECK-LABEL: test1:
 ; In static linking, we load GCC_except_table as a constant directly.
-; NOPIC:      i[[PTR]].const  $push[[CONTEXT:.*]]=, __wasm_lpad_context
+; NOPIC:      i[[PTR]].const  $push[[CONTEXT:.*]]=, [[ALIGNMENT]]
 ; NOPIC-NEXT: i[[PTR]].const  $push[[EXCEPT_TABLE:.*]]=, GCC_except_table1
-; NOPIC-NEXT: i[[PTR]].store  {{[48]}}($pop[[CONTEXT]]), $pop[[EXCEPT_TABLE]]
+; NOPIC-NEXT: i[[PTR]].store  __wasm_lpad_context($pop[[CONTEXT]]), $pop[[EXCEPT_TABLE]]
----------------
dschuff wrote:

It's interesting that this transformation eagerly swaps these 2 constants, even though it's not actually an optimization. I'm a little bit ambivalent about this because the original actually looks more natural to me (i.e. the operand contains the actual address, and the offset field is actually an offset). OTOH adding more complexity to the transform to prevent this doesn't seem great either, considering that it's not really any worse.

It does suggest though that we might be able to do a further optimization of actually combining these constants in the compiler? In an isolated case like this we couldn't actually remove the i32.const entirely (since there still needs to be an operand), and the constant offset field is always there, so it would potentially be of no benefit. But if we combine them into the offset and leave behind an `i32.const 0`, it's plausible that some subsequent optimization could remove it where appropriate. And this is a point where we have the information that the add is `nuw` so it's legal to do, whereas some subsequent pass (or post-link optimizer like Binaryen) might not have it. So it still seems worthwhile.

https://github.com/llvm/llvm-project/pull/145829