This is motivated by the need to express the structure of image
load/store/sample instructions and their corresponding intrinsics in the
AMDGPU backend, but I'm writing this mail to raise awareness in case
others find this functionality useful.
For an example usage, there are machine instructions for loading data
from images that are equivalent except for the size of the vectors they
return. At certain points, we need to map from an instruction with
vector size N to an instruction with vector size M.
The old approach used InstrMapping, which has the disadvantage of only
allowing 1:M mappings -- so in fact we had multiple InstrMappings to
support the different values of N.
The extended generic tables allow us to instead have a generic table
with the fields [Opcode, BaseOpcode, NumDwords] and two lookup functions
- looking up a row of the table by Opcode
- looking up a row of the table by (BaseOpcode, NumDwords)
This then allows mapping the old Opcode to the corresponding BaseOpcode,
and from there to the new Opcode (matched with the required vector size).
[The actual implementation of this is more involved, because in reality
the matrix of Opcodes derived from a single BaseOpcode depends on more
factors than just a single vector size. The gory details are at
https://reviews.llvm.org/D48016 and the stack of patches it belongs to.]
I also have patches that transition the existing uses of SearchableTable
to the new primitives. I believe it makes sense to remove the old
SearchableTable once the dust has settled.