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

[Jeroen Dobbelaere via llvm-dev]

Hi Martin et al,

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

At Synopsys, we do have and provide such tools (and they also use LLVM).

For more information, you can check: <https://www.synopsys.com/dw/ipdir.php?ds=asip-designer>
or you can contact me directly.

Greetings,

Jeroen Dobbelaere


> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> Martin J. O'Riordan via llvm-dev
> Sent: Thursday, August 24, 2017 12:21
> To: 'Hal Finkel' <hfinkel at anl.gov>; 'David Chisnall'
> <David.Chisnall at cl.cam.ac.uk>; 'LLVM Developers' <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Extending TableGen's 'foreach' to work with
> 'multiclass' and 'defm'
> 
> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-
> 2Dbin_mailman_listinfo_llvm-
> 2Ddev&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=ELyOnT0WepII6UnFk-
> OSzxlGOXXSfAvOLT6E8iPwwJk&m=3CaXxl5qLdyIkph7nyWPmXGMujtWrfGy1
> vhu4HTioOE&s=4-n_marejkaKSUFZsrDX4E9l1P5iecvKUbpkvIlccpk&e=