This patch tries to fold integers whose bit width is greater than 64.
motivated by https://reviews.llvm.org/D146622 landing failure
Depends on https://reviews.llvm.org/D150515
Differential D150422
[ConstantFolding] fold integers whose bitwidth is greater than 64. khei4 on May 11 2023, 9:37 PM. Authored by
Details This patch tries to fold integers whose bit width is greater than 64. Depends on https://reviews.llvm.org/D150515
Diff Detail
Unit Tests
Event TimelineComment Actions
We currently don't specify the precise memory contents for non-byte-sized integers, so it's not really possible to fold such cases now. (We only specify what happens if you store an i4 and load i4, but for example not what happens if you store i4 and then load i8.)
Comment Actions @nikic Thank you for your review!
So, does it mean loading by different bit-width is undefined behavior? It sounds like we can fold it by the value by assuming a non-byte-size integer is allocated with a bigger byte-sized type! (but does it break something? Comment Actions apply feedback and fold all integers tentatively.
Comment Actions @RKSimon Thank you for the review!
Yeah, I now find current byte-based folding is broken for well-defined loading for non-byte-size integers... I'll focus on only the removal of a 64-bit limit for this revision:) Edit: sign bit handling needed
Comment Actions focus on byte-sized integers. Comment Actions @nikic Thank you for the good catches!
Comment Actions It looks like the @load-43bit test case fails in pre-merge checks. Note that for the non-byte-sized check the important part is that the integer in the global has non-byte-size, not the type used to load from it. Comment Actions @nikic Thanks! Sorry, for that failure, it seems I just uploaded a broken test. Further checking find that current behavior seems to properly fold the non-byte-sized integer by if it's loaded with the same type. So I decided to remove the TODO comment and non-byte-integers tests! BTW, if non-byte-integers loading by a different size integer type is undefined, language reference seems to say nothing about it, at least integer and load sections. Is this a room to add a note? or I missed some related sections? Comment Actions LGTM
This should say 64. This is specified in https://llvm.org/docs/LangRef.html#id209 and https://llvm.org/docs/LangRef.html#id214. But current semantics are not really clear/inconsistent, see also discussion on D123991. Comment Actions @nikic Thank you! I'll fix the descriptions!
Ah, I missed the load semantics section... Thank you for sharing! |