[llvm-dev] TableGen: more powerful generic tables as successor of SearchableTable

Nicolai Hähnle via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 11 06:05:35 PDT 2018


Hello all,

I'd like to briefly let you know that I want to extend what the 
"searchable tables" backend of TableGen can do in terms of emitting 
generic enums and tables.

The patch is at https://reviews.llvm.org/D48013

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 
that allow:

- 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.

Feedback is welcome!

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.


More information about the llvm-dev mailing list