Emit getelementptr inbounds nuw flag where possible

[kubo39]

LLVM 19 introduces new getelementptr flag nuw.
inbounds + nuw implies that the offset is non-negative, so this could be useful for eliminating bounds/overflow check.

see also: https://discourse.llvm.org/t/rfc-add-nusw-and-nuw-flags-for-getelementptr/78672

[JohanEngelen]

Is this correct? For p == 0xffff_ffff_ffff_0000 and i == 0x1_0000, there would be overflow (in unsigned sense).

[JohanEngelen]

Maybe a better example is where i is negative.

[JohanEngelen]

"For inbounds all rules of the nusw keyword apply"
"A corollary is that if the getelementptr is both nusw and nuw, the offset must be non-negative"
So I think this PR is not correct when i can be negative (as in this test case).

[kubo39]

You're right, but we can't guarantee inbounds for any of the pointer operations also, can we?

[JohanEngelen]

You're right, but we can't guarantee inbounds for any of the pointer operations also, can we?

I think we can, by language spec, because out of bounds would be UB (as specced).

[JohanEngelen]

Please be very thorough in proving that this is correct. I fear that if this is slightly incorrect, that it can lead to hard to debug miscompiles at high optimization levels.

[JohanEngelen]

I know it is extra work, but perhaps it is best to put this behind a flag? Then we can "test" its correctness easily on large codebases and eliminate the risk of shipping a broken (default settings) compiler.

[kubo39]

I know it is extra work, but perhaps it is best to put this behind a flag? Then we can "test" its correctness easily on large codebases and eliminate the risk of shipping a broken (default settings) compiler.

Agreed.

(The current implementation is conservative, so it shouldn't impact performance, but I think it's a good place to start.)