================
@@ -283,10 +283,12 @@ static bool shouldCompletelyUnroll(const Stmt *LoopStmt,
ASTContext &ASTCtx,
llvm::APInt InitNum =
Matches[0].getNodeAs<IntegerLiteral>("initNum")->getValue();
auto CondOp = Matches[0].getNodeAs<BinaryOperator>("conditionOperator");
- if (InitNum.getBitWidth() != BoundNum.getBitWidth()) {
- InitNum = InitNum.zext(BoundNum.getBitWidth());
- BoundNum = BoundNum.zext(InitNum.getBitWidth());
- }
+ unsigned MaxWidth = std::max(InitNum.getBitWidth(), BoundNum.getBitWidth());
----------------
shenjunjiekoda wrote:
Thank you for your thoughtful feedback!
In Clang's AST, `IntegerLiteral` represents unsigned integer values. To
represent a literal like `-1`, the AST typically uses a combination of
`UnaryOperator(-)` and `IntegerLiteral`.
Regarding zero extension (`zext`), it is semantically correct here because
`APInt` (the return type of `IntegerLiteral::getValue()`) inherently represents
unsigned values.
I considered whether tools like `APSIntType` could simplify this logic.
However, since this operation deals specifically with unsigned integers
(APInt), using APSIntType would introduce unnecessary complexity for signed
semantics, which is not required here. The current use of APInt ensures
precision and correctness.
On whether we could switch to `int64`, I think converting to int64 might not
simplify the code too much.
Let me know if further clarification or adjustments are needed!
https://github.com/llvm/llvm-project/pull/121203
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
