[Attributes] Make intrinsic attribute generation more flexible (NFC)
authorNikita Popov <npopov@redhat.com>
Tue, 11 Oct 2022 11:56:06 +0000 (13:56 +0200)
committerNikita Popov <npopov@redhat.com>
Wed, 12 Oct 2022 08:56:01 +0000 (10:56 +0200)
commit2a26a445b342b0fa6090e8e99bf1fd0f18f6f7df
tree87afbefd3a07b43a6bd573f95a9a800bbb1695ae
parent0577a9f8d06b97bf8b4d9aa171096e0797e4f5d1
[Attributes] Make intrinsic attribute generation more flexible (NFC)

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.

Differential Revision: https://reviews.llvm.org/D135679
llvm/test/TableGen/intrin-properties.td [deleted file]
llvm/test/TableGen/intrin-side-effects.td
llvm/utils/TableGen/CodeGenIntrinsics.h
llvm/utils/TableGen/IntrinsicEmitter.cpp