[llvm-dev] Extending TableGen's 'foreach' to work with 'multiclass' and 'defm'

[Martin J. O'Riordan via llvm-dev]

The compilers I maintain are for our own custom hardware processor designs, so it is normal for the hardware and tools to be developed in conjunction with each other; and a question I am asked about twice a year is:

  "can we not just generate the tool-chain from the machine description?"

Seems simple enough, no?  The object being to have a single definitive statement of the machine, and from that derive the RTL, silicon, documentation, assembler, compiler, debugger, simulator, etc.  It’s a neat objective, but not well realised.

There have been attempts in the past, but they always seem to fizzle out after a while, often because they begin as University PhD research topics, and after the original dissertation is completed, they just seem to die.

'ArchC' was an example, and 'AACGen', but I haven't seen any progress on this since 2013, and even then it was using LLVM v2.7 (or possible older).  I just had a quick look at the website for ArchC, and it seems that it is still stuck in 2013 :-(

Hal's comment "unless we can also have that tool in tree" I think is important, because if an alternative to TableGen is devised, then having its source within the LLVM tree ensures that it will be maintained and will develop over time.

	MartinO

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via llvm-dev
Sent: 23 August 2017 19:45

>> There are also external tools that both produce and consume the TableGen sources.  Having
>> a language that is *not* a general-purpose programming language is a feature for these
>> tools, not an obstacle.
>
> I think that this goes both ways. For in-tree targets at least, we want 
> the source that is intended to be maintained by a human in tree. So, the 
> fact that an external tool can produce TableGen doesn't really solve the 
> problem (unless we can also have that tool in tree, and moreover, I 
> don't want to encourage each backend to develop their own such tools 
> independently).
>
>   -Hal