erichkeane wrote:
> The parallel-array machinery is over-fitted for a multi-bundle world CIR
> doesn't actually use. Every Clang builtin that lowers to `llvm.assume` with
> bundles emits exactly one (`align`, `separate_storage`, `dereferenceable`),
> so I'd propose a single-bundle shape with a kind enum:
>
> ```
> def CIR_AssumeBundleKindAttr : I32EnumAttr<"AssumeBundleKind",
> "kind of cir.assume operand bundle", [
> I32EnumAttrCase<"None", 0>,
> I32EnumAttrCase<"Align", 1, "align">,
> I32EnumAttrCase<"SeparateStorage", 2, "separate_storage">,
> I32EnumAttrCase<"Dereferenceable", 3, "dereferenceable">
> ]>;
>
> def CIR_AssumeOp : CIR_Op<"assume"> {
> let arguments = (ins
> CIR_BoolType:$predicate,
> DefaultValuedAttr<CIR_AssumeBundleKindAttr,
> "::cir::AssumeBundleKind::None">:$bundle_kind,
> Variadic<CIR_AnyType>:$bundle_args
> );
> // cir.assume %true align(%p, %a : !cir.ptr<!void>, !u64i) : !cir.bool
> // cir.assume %true : !cir.bool (no bundle; kind defaults to None)
> let hasVerifier = 1;
> }
> ```
>
> Gone: `VariadicOfVariadic`, the segment-sizes array, the ~85 lines of custom
> `printOpBundles` / `parseOpBundles` in `CIRDialect.cpp`. The (kind absent,
> args present) invalid state is structurally gone -- kind is always present,
> defaults to `None`. The verifier collapses to a per-kind arity check, which
> is the "abstract out each bundle kind" explicit per-kind shape you flagged.
>
> Lowering goes back to a two-branch shape (`LLVM::AssumeOp::build(cond)` for
> `None`, `build(cond, stringifyAssumeBundleKind(kind), args)` otherwise) --
> not the branchless parallel-array forward we had, but structurally honest for
> the single-bundle case (the two forms are genuinely distinct entry points in
> the LLVM dialect builder).
>
> Is this the shape you had in mind, or something else?
I mean, I was happy with/requested a assume-has-a-single-bundle-kind earlier,
but you'd added the additional complexity in your last patch for seemingly no
reason, all I'd requested is to have the two packaged together, to keep arity
correct.
Given the above, why do you still need a verifier?
Side note: Is the above LLM generated text? I have quite a few
comments/reviews that i believe you've done that with, and it makes it VERY
difficult to actually review your code/ideas. You're generating a substantial
amount of work for reviewers.
https://github.com/llvm/llvm-project/pull/197262
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
