Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Looks reasonable to me. My only slight concern is that the implementation could be more precise when offset and width are not exactly known - but I don't know if there's any point in trying to optimize that case.
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
524–525 | For example, instead of expanding the calculation "(1 << Width) - 1" literally here, I think you might get better results with something like: KnownBits Mask; Mask.Zero = APInt::getBitsSetFrom(BitWidth, WidthKnown.getMaxValue()); Mask.One = APInt::getLowBitsSet(BitWidth, WidthKnown.getMinValue()); |
llvm/unittests/CodeGen/GlobalISel/KnownBitsTest.cpp | ||
---|---|---|
1794 | Can you also test computeNumSignBits? It may just work as is |
Addressed review comments.
Use getBitsSetFrom and getLowBitsSet to compute mask for the width operand
of G_SBFX/G_UBFX as suggested.
Added tests for computeNumSignBits for G_SBFX/G_UBFX.
Fix clang-tidy formatting issues.
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
524–525 | Thanks for the suggestion. I use getBitsSetFrom/getLowBitsSet when the Width value is known. I think generating the mask explicitly or creating the literal calculation should generate the same results. But, when the width is known, it makes sense to just create the mask explicitly. |
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
524–525 | I don't understand why WidthKnown.isUnknown() should be a special case. But you might need some strategic std::mins to avoid passing a value larger than BitWidth into getBitsSetFrom/getLowBitsSet. |
Removed check for isUnknown, and limit value to BitWidth, as suggested in the review.
What about G_SBFX handling in GISelKnownBits::computeNumSignBits?
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
528 | Are you going to have any issues here when Mask.hasConflict() is true? |
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
528 | That can only happen if WidthKnown.getMinValue() > WidthKnown.getMaxValue(), which I guess can only happen if WidthKnown.hasConflict() was already true. What are the rules about introducing or propagating conflicts? |
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
528 | Well, we do assert there is no conflict at the end of GISelKnownBits::computeKnownBitsImpl so we should be ensuring this doesn't happen. |
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
528 | Right, but I'm saying that this code can't produce a conflict out of thin air, only if one of the inputs already had a conflict, so I *think* it's OK. Would you agree? |
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
528 | I'm not sure what, if anything, needs to be done to handle a conflict here? Appreciate any suggestions. |
LGTM with one minor - cheers.
llvm/lib/CodeGen/GlobalISel/GISelKnownBits.cpp | ||
---|---|---|
119 | Please can you add a TODO suggesting we move this to KnownBits.h - it looks like this might be usable in other places (e.g. x86 BEXTR) in the future but until then its fine to keep it here. |
Please can you add a TODO suggesting we move this to KnownBits.h - it looks like this might be usable in other places (e.g. x86 BEXTR) in the future but until then its fine to keep it here.