This is an archive of the discontinued LLVM Phabricator instance.

[ConstantFolding] fold integers whose bitwidth is greater than 64.
ClosedPublic

Authored by khei4 on May 11 2023, 9:37 PM.

Details

Summary

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

Diff Detail

Event Timeline

khei4 created this revision.May 11 2023, 9:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 11 2023, 9:37 PM
khei4 requested review of this revision.May 11 2023, 9:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 11 2023, 9:37 PM
khei4 edited the summary of this revision. (Show Details)May 11 2023, 9:39 PM
khei4 added reviewers: nikic, RKSimon, xbolva00, spatel.
nikic added a comment.May 12 2023, 1:20 AM

(how can I confirm the correctness of not multiplies of 8 integers?)

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.)

llvm/lib/Analysis/ConstantFolding.cpp
434

This is going to assert if the value inside the i128 is larger than 64-bit. It's necessary to work on the APInt representation instead.

khei4 added a comment.May 12 2023, 3:00 AM

@nikic Thank you for your review!

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.)

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?

khei4 updated this revision to Diff 521594.EditedMay 12 2023, 3:01 AM

apply feedback and fold all integers tentatively.
(at least will be rebased after https://reviews.llvm.org/D146622 safely landed

llvm/lib/Analysis/ConstantFolding.cpp
434

Thank you!! I was careless!

khei4 edited the summary of this revision. (Show Details)May 12 2023, 3:03 AM
RKSimon added inline comments.May 12 2023, 3:25 AM
llvm/lib/Analysis/ConstantFolding.cpp
433

I'd be surprised if non-byte sized widths work at all - moving to APInt from uint64_t will allow you to remove the 64 bit limit however, so maybe just work on that first?

RKSimon added inline comments.May 12 2023, 3:28 AM
llvm/lib/Analysis/ConstantFolding.cpp
434

const APInt &Val

442

Val.extractBits(8, n * 8).getZextValue()

khei4 added a comment.EditedMay 13 2023, 2:07 AM

@RKSimon Thank you for the review!

I'd be surprised if non-byte sized widths work at all - moving to APInt from uint64_t will allow you to remove the 64 bit limit however, so maybe just work on that first?

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

khei4 planned changes to this revision.May 13 2023, 2:07 AM
khei4 retitled this revision from [ConstantFolding] fold integers whose bitwidth is greater than 63, and not multiplies of 8 to (WIP)[ConstantFolding] fold integers whose bitwidth is greater than 63..May 13 2023, 2:12 AM
khei4 edited the summary of this revision. (Show Details)
khei4 added inline comments.May 13 2023, 5:17 PM
llvm/lib/Analysis/ConstantFolding.cpp
442

Thank you! This causes test failure caused by allocsize of vector size mismatching! It will be fixed in https://reviews.llvm.org/D150515

khei4 updated this revision to Diff 522028.EditedMay 14 2023, 7:52 PM

focus on byte-sized integers.
currently, some tests failed. This will be handled at https://reviews.llvm.org/D150515#inline-1454185

khei4 retitled this revision from (WIP)[ConstantFolding] fold integers whose bitwidth is greater than 63. to [ConstantFolding] fold integers whose bitwidth is greater than 63..May 14 2023, 10:40 PM
khei4 edited the summary of this revision. (Show Details)
khei4 updated this revision to Diff 522049.May 14 2023, 10:59 PM

remove obsolete test changes

nikic added inline comments.May 15 2023, 5:50 AM
llvm/lib/Analysis/ConstantFolding.cpp
432
434
llvm/test/Transforms/InstCombine/constant-fold.ll
2 ↗(On Diff #522049)

This test can be moved to InstSimplify (shouldn't need InstCombine). There probably already is some load.ll or so file there.

khei4 updated this revision to Diff 522173.May 15 2023, 7:03 AM

apply feedbacks

khei4 added a comment.May 15 2023, 7:03 AM

@nikic Thank you for the good catches!

llvm/lib/Analysis/ConstantFolding.cpp
434

Thanks!

llvm/test/Transforms/InstCombine/constant-fold.ll
2 ↗(On Diff #522049)

Thanks! and about following case

define i125 @load-125bit(){
; CHECK-LABEL: define i125 @load-125bit() {
; CHECK-NEXT:    ret i125 1125899906842625
;
  %1 = load i125, ptr @global125, align 4
  ret i125 %1
}

InstSimplify somehow fold this on the current released opt https://llvm.godbolt.org/z/o5cz6ds99

so by changing the condition slightly, load 128-bit integer as 43-bit integer(I am not so sure why this happens.

define i43 @load-43bit(){
; CHECK-LABEL: @load-43bit(
; CHECK-NEXT:    [[TMP1:%.*]] = load i43, ptr @global128, align 4
; CHECK-NEXT:    ret i43 [[TMP1]]
;
  %1 = load i43, ptr @global128, align 4
  ret i43 %1
}
nikic added a comment.May 15 2023, 1:23 PM

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.

khei4 added a comment.EditedMay 15 2023, 6:42 PM

@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
https://github.com/llvm/llvm-project/blob/7c1fb94150449db33f2df4567207387710e515b9/llvm/lib/Analysis/ConstantFolding.cpp#L348-L353

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?

khei4 updated this revision to Diff 522408.May 15 2023, 6:58 PM

remove non-byte-integer related todo and tests

nikic accepted this revision.May 16 2023, 1:19 AM

LGTM

[ConstantFolding] fold integers whose bitwidth is greater than 63.

This should say 64.

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?

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.

This revision is now accepted and ready to land.May 16 2023, 1:19 AM
khei4 added a comment.May 16 2023, 2:55 AM

@nikic Thank you! I'll fix the descriptions!

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.

Ah, I missed the load semantics section... Thank you for sharing!

khei4 retitled this revision from [ConstantFolding] fold integers whose bitwidth is greater than 63. to [ConstantFolding] fold integers whose bitwidth is greater than 64..May 16 2023, 2:55 AM
khei4 edited the summary of this revision. (Show Details)
This revision was landed with ongoing or failed builds.May 16 2023, 7:09 PM
This revision was automatically updated to reflect the committed changes.