We're missing SimplifyDemandedBits styles of optimizations,
so one case differs from the DAG from not trimming the constant.
The other case is an optimization we get that the DAG doesn't do to
split the 64-bit shift.
Details
Diff Detail
Event Timeline
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
723 | Probably should still factor this in |
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
609 | Needs a comment, and possibly a better name, since this is not just looking at the range metadata, it is also handling different kinds of load opcode. | |
630 | How could we hit this? | |
723 | If you can rely on MMO->getSizeInBits() == CR.getBitWidth() then computeNumSignBitsFromRangeMetadata has already done this. |
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
630 | The anyextload case (or if the metadata was on a casted to vector result type) |
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
630 | It's the case where every load is legalized to an s32 (which I'd like to stop doing eventually). Apparently it's not reachable in the globalisel version since we don't handle the extract_vector_elt look through yet | |
633 | This was to defend against the vector case, TyBits is the scalar size | |
692 | You're only looking for element 0 if it's a vector result type |
Add mir test (although kind of pointless, we can't hit this case here yet). Also copy the endianness check from the DAG version
Needs a comment, and possibly a better name, since this is not just looking at the range metadata, it is also handling different kinds of load opcode.