-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[DAG] Improve known bits of Zext/Sext loads with range metadata #80829
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3645,32 +3645,42 @@ KnownBits SelectionDAG::computeKnownBits(SDValue Op, const APInt &DemandedElts, | |
} | ||
} | ||
} | ||
} else if (ISD::isZEXTLoad(Op.getNode()) && Op.getResNo() == 0) { | ||
// If this is a ZEXTLoad and we are looking at the loaded value. | ||
EVT VT = LD->getMemoryVT(); | ||
unsigned MemBits = VT.getScalarSizeInBits(); | ||
Known.Zero.setBitsFrom(MemBits); | ||
} else if (const MDNode *Ranges = LD->getRanges()) { | ||
EVT VT = LD->getValueType(0); | ||
|
||
// TODO: Handle for extending loads | ||
if (LD->getExtensionType() == ISD::NON_EXTLOAD) { | ||
} else if (Op.getResNo() == 0) { | ||
KnownBits Known0(!LD->getMemoryVT().isScalableVT() | ||
? LD->getMemoryVT().getFixedSizeInBits() | ||
: BitWidth); | ||
EVT VT = Op.getValueType(); | ||
// Fill in any known bits from range information. There are 3 types being | ||
// used. The results VT (same vector elt size as BitWidth), the loaded | ||
// MemoryVT (which may or may not be vector) and the range VTs original | ||
// type. The range matadata needs the full range (i.e | ||
// MemoryVT().getSizeInBits()), which is truncated to the correct elt size | ||
// if it is know. These are then extended to the original VT sizes below. | ||
if (const MDNode *MD = LD->getRanges()) { | ||
computeKnownBitsFromRangeMetadata(*MD, Known0); | ||
if (VT.isVector()) { | ||
// Handle truncation to the first demanded element. | ||
// TODO: Figure out which demanded elements are covered | ||
if (DemandedElts != 1 || !getDataLayout().isLittleEndian()) | ||
break; | ||
Known0 = Known0.trunc(BitWidth); | ||
} | ||
} | ||
|
||
// Handle the case where a load has a vector type, but scalar memory | ||
// with an attached range. | ||
EVT MemVT = LD->getMemoryVT(); | ||
KnownBits KnownFull(MemVT.getSizeInBits()); | ||
if (LD->getMemoryVT().isVector()) | ||
Known0 = Known0.trunc(LD->getMemoryVT().getScalarSizeInBits()); | ||
|
||
computeKnownBitsFromRangeMetadata(*Ranges, KnownFull); | ||
Known = KnownFull.trunc(BitWidth); | ||
} else | ||
computeKnownBitsFromRangeMetadata(*Ranges, Known); | ||
} | ||
// Extend the Known bits from memory to the size of the result. | ||
if (ISD::isZEXTLoad(Op.getNode())) | ||
Known = Known0.zext(BitWidth); | ||
else if (ISD::isSEXTLoad(Op.getNode())) | ||
Known = Known0.sext(BitWidth); | ||
else if (ISD::isEXTLoad(Op.getNode())) | ||
Known = Known0.anyext(BitWidth); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you need to guard against FP type ext loads? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It looks like we don't create extending loads with ISD opcode FP_EXTEND - we'll just create a normal load followed by a separate FP_EXTEND node. Perhaps there is a way to assert this, i.e. assert for FP types that memory VT == results VT? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm. As far as I can tell fp loads will not have range data, and so if we have a anyext fp load then we should get a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure MMO metadata is properly handled when bit casts are folded into load/store |
||
else | ||
Known = Known0; | ||
assert(Known.getBitWidth() == BitWidth); | ||
return Known; | ||
} | ||
break; | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,9 +21,7 @@ define noundef i1 @logger(i32 noundef %logLevel, ptr %ea, ptr %pll) { | |
; CHECK-NEXT: ret | ||
; CHECK-NEXT: .LBB1_2: // %land.rhs | ||
; CHECK-NEXT: ldr x8, [x1] | ||
; CHECK-NEXT: ldrb w8, [x8] | ||
; CHECK-NEXT: cmp w8, #0 | ||
; CHECK-NEXT: cset w0, ne | ||
; CHECK-NEXT: ldrb w0, [x8] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not enough test updates? I would expect a diff from the zext/sext/anyext cases There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps it's possible to use the range metadata to write some explicit tests for sext/anyext? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I need to add some better tests. Whilst this seems to come up a fair amount during C++ code (bools often have range metadata applied), it can be difficult to test is simple cases as the |
||
; CHECK-NEXT: ret | ||
entry: | ||
%0 = load i32, ptr %pll, align 4 | ||
|
Uh oh!
There was an error while loading. Please reload this page.