llvm dev - Mar 2015 - [LLVMdev] [cfe-dev] TargetParser - Always build all table-gen files?

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

On Mar 9, 2015, at 1:42 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 9 March 2015 at 18:21, Reid Kleckner <rnk at google.com> wrote:
> 
>> 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.
I suppose you mean “once per ‘make clean’ invocation”.   Do you have any info on
how long it takes to do this on a slow target, or on a windows machine?


Jim Rowan
jmr at codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

On 9 March 2015 at 20:50, Rowan, Jim <jmr at codeaurora.org>
wrote:
> I suppose you mean “once per ‘make clean’ invocation”.
Or if any of the table-gen files change, yes.

> Do you have any info on how long it takes to do this on a slow target, or
on a windows machine?
On my ARM chromebook2, 4 Cortex-A15 cores, after llvm-tblgen has been
compiled (took 2min40s), both "ninja -j6 libLLVMARMInfo.a" and
"ninja
-j6 libLLVMAArch64Info.a" up until the first cpp file took 14 seconds.

I assume other backends will have the same size / time. We have 13
back-ends, assuming you go from building one to building all 13,
you'll add 3 more minutes to the build. Bearing in mind that a full
build on that box takes around one hour, it's not that much, really.

This may not be the best way of doing it, but I don't think it's time
added enough, especially considering the enormous amount of complexity
that this will remove from Clang, LLVM, and all other tools. It may
even speed up the build, as well as allow us to implement sane
interfaces and APIs across the board.

cheers,
-renato