================
@@ -2941,22 +2941,27 @@ mlir::LogicalResult cir::FuncOp::verify() {
// AddOp / SubOp
//===----------------------------------------------------------------------===//
-// The integer-only type constraint on these ops makes the nsw/nuw/sat flag
-// type checks unnecessary. Only the mutual-exclusivity between nsw/nuw and
-// sat needs to be verified.
+static LogicalResult verifyAddSubFlags(Operation *op, Type type, bool nsw,
+ bool nuw, bool sat) {
+ if ((nsw && nuw) || (sat && (nsw || nuw)))
----------------
bcardosolopes wrote:
I think the two rules here aren't independent.
The patch adds two things: nsw requires a signed type / nuw requires an
unsigned type, and nsw/nuw/sat are mutually exclusive. Because CIR integer
types carry signedness, the first rule already implies the nsw+nuw half of the
second. There is no CIR type for which both checks can pass, so the decision
you're asking about is really "do we keep the type pairing", not "do we forbid
the pair".
And the type pairing I'm comfortable with. It's the thing that makes CIR's
typed integers worth having: in LLVM the flags carry the signedness because
`i32` doesn't, and here the type does, so a `nuw` on `!s32i` isn't a stronger
fact, it's a contradiction. IIUC, nothing in tree disagrees either, across all
of `clang/test/CIR` there is no`cir.add`/`cir.sub` with `nuw` on a signed type,
`nsw` on an unsigned one, or both flags at once.
On your specific worry, needing both to match classic: `clang/lib/CodeGen` has
no `setHasNoUnsignedWrap` call anywhere. Every NUW it produces goes through
`CreateNUWMul` / `CreateNUWAdd` / `CreateNUWSub`, all of which set NUW alone,
and the interesting ones (`CGExprScalar.cpp:3885` and `:5008`, the
pointer-difference element scaling) are on `size_t`, which is unsigned on our
side too. So the frontend never wants the pair.
Maybe we should be more careful with the framing than with the rule. This is a
CIR policy resting on CIR having signed types, not a restatement of LLVM
semantics, and the description should say so, otherwise the next person reads
it as "nsw nuw is invalid" and gets a surprise the first time they look at LLVM
IR. If a pass ever does derive both facts about the same op, the answer is that
op has one type and only one of the two facts is expressible, which is a real
limitation to write down now rather than discover later.
https://github.com/llvm/llvm-project/pull/218398
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
