[llvm-dev] Extending TableGen's 'foreach' to work with 'multiclass' and 'defm'
Alex Bradbury via llvm-dev
llvm-dev at lists.llvm.org
Tue Aug 22 01:59:03 PDT 2017
On 21 August 2017 at 13:23, Martin J. O'Riordan via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> But there is a downside.
>
> For each of the above I also have variations that are a result of different
> processor and ISA versions, and because of this I have to use
> ‘multiclass/defm’ to define the descriptions along with ‘Require’
> predicates. The same approach does not work with ‘multiclass/defm’ though,
> because TableGen does not support ‘foreach’ with ‘multiclass/defm’.
>
> I have experimented with adapting TableGen to do this, but I am just not
> knowledgeable enough about how TableGen works and my attempts have not been
> successful. Perhaps some of the people debating the separation of
> instruction and patterns topic might have some insight into how TableGen
> might be adapted to support ‘foreach’ with ‘multiclass/defm’ definitions and
> could advise me how I should do this; or maybe the maintainers of TableGen
> might consider this something that they would be willing to add to TableGen
> in the future?
Hi Martin, I think this is an interesting topic. I've also run up
against the limitations of foreach, though for my particular case the
variable-sized register class work provides a better solution.
I will note that at least one backend (Hexagon) has moved towards
using TableGen as a fairly 'dumb' data definition language, relying on
a separate tool for generating instruction definitions. I'd be curious
to know if others are using this approach. It'd also imaging that
using m4/jinja or similar as a .td preprocessor would be a potential
option for an out-of-tree backend, in cases where TableGen macro
support and programmability is too weak.
I suppose one question is: would allowing foreach to be used with
multiclass/defm be sufficient to allow TableGen to be a productive and
maintainable way of defining complex architectures, or would there be
a number of other deficiencies that might push you towards larger
TableGen extensions or using a separate tool or preprocessor?
Best,
Alex
More information about the llvm-dev
mailing list