[cfe-dev] TargetParser - Always build all table-gen files?

[Renato Golin]

On 9 March 2015 at 18:21, Reid Kleckner <rnk at google.com> wrote:
> To be clear, TargetParser is about parsing subtarget CPUs and features,
> right?

In the first stage, yes. But there's a lot more. I hope this ends up
being a much larger infrastructure to query for target support, not
just parsing strings (which we can cope with duplication), but
defining architectural behaviour, which is a whole different case.

Clang is only one user. Ever other front-end has to do the same. All
other tools (lli, llc, etc) have to duplicate string parsing, and any
out-of-tree plugin will have to do the same, if they need anything
that is not built as a back-end.

There is a lot in Clang's driver that could be greatly simplified if
we had a proper unified target description.


> I'm not very familiar with how the current system works, but it would be a
> shame to run tablegen for all targets when the user just wants one backend.

Why? The only effect of this is to process all targets' table-gen
files at build time, mostly once for the targets you rarely use. They
will not be included in any library, binary or archive if you don't
use the specific back-end, and the TargetParser will only use the
necessary tables to get target information.


> The subtarget feature flags aren't very much data. If I were doing this
> today, I would make one subtarget info library and put all the subtarget
> features in there. The subtarget information is far less than the
> instruction table information. For example:
> lib/Target/Subtargets/X86Subtargets.td
> lib/Target/Subtargets/ARMSubtargets.td

It's not just CPU names. For instance, Clang has support for register
names. Right now, they're all accepted (x86 names for ARM code)
because Clang doesn't know better. Another example is assembler /
linker flags (-Wa,-Wl), which are not supported at all for the
integrated assembler and would be another user of parsing and
inspecting capabilities.

All the information is there, in the table-gen files, and could be
easily accessed into an abstraction layer (TargetDescription or
whatever), which TargetParser could use, as well as all other tools,
including lld, lldb, etc. We're not talking about duplication, we're
talking about multiplication by a factor a lot more than two.

cheers,
--renato