Currently attributes for intrinsics are emitted using the ArrayRef<AttrKind> based constructor for AttributeLists. This works out fine for simple enum attributes, but doesn't really generalize to attributes that accept values. We're already doing something awkward for alignment attributes, and I'd like to have a cleaner solution to this with https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579 in mind.
The new generation approach is to instead directly construct Attributes, giving us access to the full generality of that interface. To avoid significantly increasing the size of the generated code, we now also deduplicate the attribute sets. The code generated per unique AttributeList looks like this:
case 204: { AS[0] = {1, getIntrinsicArgAttributeSet(C, 5)}; AS[1] = {AttributeList::FunctionIndex, getIntrinsicFnAttributeSet(C, 10)}; NumAttrs = 2; break; }
and then the helper functions contain something like
case 5: return AttributeSet::get(C, { Attribute::get(C, Attribute::NoCapture), });
and
case 10: return AttributeSet::get(C, { Attribute::get(C, Attribute::NoUnwind), Attribute::get(C, Attribute::ArgMemOnly), });
A casualty of this change is the intrin-properties.td test, as I don't think that FileCheck allows matching this kind of output.
I guess the alternative would be to have another hasAtLeastOneAttribute bool in the entries for UniqFnAttributes that's set when populating UniqFnAttributes, but that's not that much better