[FXML-4501] Lower arith.andi, arith.ori, arith.shli, arith.shrsi, arith.shrui, arith.xori to emitc

[cferry-AMD]

No description provided.

[mgehre-amd]

C++ about shift operations:

The behavior is undefined if the right operand
is negative, or greater than or equal to the length in bits of the promoted left operand.

and the MLIR shift ops say

If the value of the second operand is greater or equal than the bitwidth of the first operand, then the operation returns poison.

Here, negative in the C++ world is the same as greater or equal in the emitc world as we cast the right operand to unsigned before.
Formally, undefined behavior is stronger than poison as it can time-travel.
I think we either need to check statically that no UB happens, or emit an runtime guard for it.

[mgehre-amd]

Alternatively, checking the nuw/nsw flags on arith.shli might guarantee that the shift amount is valid. I haven't looked to much which of them is applicable here.

[mgehre-amd]

Alternatively, checking the nuw/nsw flags on arith.shli might guarantee that the shift amount is valid. I haven't looked to much which of them is applicable here.

Ah, those flags don't constraint the shift amount. A better description of them is in the LLVM spec: https://llvm.org/docs/LangRef.html#shl-instruction

[cferry-AMD]

Static checking is only possible when the amount of the right shift is statically known, which practically means a constant. So, in the general case we'll need to introduce runtime checks.

However, I'm not sure of how to deal with anything that relies on poison values. There's no poison semantics in C/C++, and I have too little understanding of the differences between poison and undefined behavior to actually know what to do.

[cferry-AMD]

In the runtime check, I resorted to using sizeof for index types instead of rejecting them. I expect that the compiler does constant folding and strength reduction when the shift amount is a constant, to avoid introducing a shortcut.

[josel-amd]

LGTM

[TinaAMD]

LGTM