This is an archive of the discontinued LLVM Phabricator instance.

[InstructionSimplify][FIX] Handle bit widths in the presence of AS-casts
AbandonedPublic

Authored by jdoerfert on Feb 14 2022, 10:42 AM.

Details

Reviewers
arsenm
hliao
nikic
Summary

While D64768 fixed some problems, it did not make sure we always keep
matching types for constant offsets in the presence of AS-casts.

The new approach is mostly keeping the constant offset bit width in sync
with the original value type (in the spirit of D118727). That said, if
we perform multiple strip operations we still need to adjust the types
if the first pointer strip causes a bit width change.

NOTE: Test is WIP.

Diff Detail

Event Timeline

jdoerfert created this revision.Feb 14 2022, 10:42 AM
jdoerfert requested review of this revision.Feb 14 2022, 10:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 14 2022, 10:42 AM
Herald added a subscriber: wdng. · View Herald Transcript

It makes it easier to fix but without testing it I would not assume the issue is gone.
The strip calls can still yield constants with different bit-width as they are matched to the bit-width of the resulting value.
So LHS/RHS that come out of the strip call can have different types and address spaces, and the constant offsets can have different bit-widths.

If we always return the constants with bit-widths matching the inputs (which I do here), the only remaining problem is that we call stripPointerCasts first, which causes the LHS/RHS to be "not in sync" when we call stripAndAccumulate. (see my comment in the code).

llvm/lib/Analysis/InstructionSimplify.cpp
2577

^Here

nikic added a comment.Feb 16 2022, 1:12 AM

It makes it easier to fix but without testing it I would not assume the issue is gone.
The strip calls can still yield constants with different bit-width as they are matched to the bit-width of the resulting value.
So LHS/RHS that come out of the strip call can have different types and address spaces, and the constant offsets can have different bit-widths.

The reason why I'd expect it to be fixed is that RHSOffset and LHSOffset only get used together if RHS == LHS now, in which case the type of the (offset-stripped) pointers match and as such should also have the same index size.

If we always return the constants with bit-widths matching the inputs (which I do here), the only remaining problem is that we call stripPointerCasts first, which causes the LHS/RHS to be "not in sync" when we call stripAndAccumulate. (see my comment in the code).

Not just that, but computePointerICmp() itself may be called on different types -- apparently, it looks through ptrtoint.

jdoerfert abandoned this revision.Feb 16 2022, 8:21 AM

It makes it easier to fix but without testing it I would not assume the issue is gone.
The strip calls can still yield constants with different bit-width as they are matched to the bit-width of the resulting value.
So LHS/RHS that come out of the strip call can have different types and address spaces, and the constant offsets can have different bit-widths.

The reason why I'd expect it to be fixed is that RHSOffset and LHSOffset only get used together if RHS == LHS now, in which case the type of the (offset-stripped) pointers match and as such should also have the same index size.

I think you are right.