For context, the proposed RISC-V bit manipulation extension has a subset
of instructions which require one of two SubtargetFeatures to be
enabled, 'zbb' or 'zbp', and there is no defined feature which both of
these can imply to use as a constraint either (see comments in D65649).
AssemblerPredicates allow multiple SubtargetFeatures to be declared in
the "AssemblerCondString" field, separated by commas, and this means
that the two features must both be enabled. There is no equivalent to
say that _either_ feature X or feature Y must be enabled, short of
creating a dummy SubtargetFeature for this purpose and having features
X and Y imply the new feature.
To solve the case where X or Y is needed without adding a new feature, I
propose extending the supported syntax in the "AssemblerCondString" to
create constraints which meet this need. Since a single comma is used
to mean and, I propose using a vertical bar to mean or, since this
matches the mental model when glancing at predicate definitions. I have
modified TableGen's AsmWriterEmitter, FixedLenDecoderEmitter and
SubtargetFeatureInfo's computeAssemblerAvaiableFeatures emitter to
emit code which achieves this result.
(As an aside, this includes a proposed method of consuming sets of
features or'd together in a set of conditions that are typically all
combined with ands).
At this stage, it is illegal to combine features with ands and ors in
a single AssemblerCondString. I suspect this case is sufficiently rare
that adding more complex changes to support it are unnecessary.
If this seems like a sensible feature, I intend to update this review
with some unit tests (and submit the RISCV change separately), but for
now showing the two together demonstates the type of thing I would like