[LLVMdev] Tablegen question

Dan Gohman gohman at apple.com
Fri Jun 12 14:11:20 PDT 2009

On Jun 9, 2009, at 1:16 PM, Manjunath Kudlur wrote:

>> All of the tablegen backends work this way. As you mentioned,
>> there are no target-specific tablegen backends at present.
>> The underlying observation here is that features are never
>> fundamentally "specific for a target". For example, a mapping
>> between vector opcodes and associated scalar opcodes could
>> reasonably be made on many architectures. Even
>> load-balancing between functional units on a processor is a
>> target-independent concept, with details like the number and
>> nature of the functional units being target-dependent.
> Sorry to be such a pest, but I am still trying to understand the usage
> model for tablegen. Are you saying it is not a good idea to write a
> tablegen backend for something very specific to a target?

The underlying observation here is that features are never
fundamentally "specific for a target".

> The examples
> I gave happen to be applicable to many targets. But the usage depends
> on AN implementation of codegen for a target, no? I mean, I could
> choose to put the related scalar instruction in a field with a
> specific name in the myInst class in the .td file, and would want to
> populate a data structure with a specific name in my C++ code. The
> tablegen backend should "know" the names of both the field in the .td
> file and the name of the data structure. How can I make this generic?

It's hard to say without knowing more details, but in general the
way to do this is to make the data-types used in your C++ code
target-independent. Obviously the actual data would be
target-dependent. Then the code that uses the data structures and
the tablegen backend could both be target-independent.

In general, when features are designed in this way, it is easier
to reuse the code for new targets.


More information about the llvm-dev mailing list