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

On 10 March 2015 at 16:20, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> I’d like to avoid as much as possible adding compilation time to the
process unless it is necessary (I’m not saying it does not worth it here).
As I said in the review, it may end up being faster, because of the
amount of crap we'll remove from all tools and LLVM.

> It is not clear to me why do you need to generate *all* the table-gen files
and not only the one related to target features?
I don't know which of them yet, but I'll certainly need CPU/FPU/ARCH
names, register names, feature names and anything to populate a target
description object.

I moved them all into the include file because I didn't want to have
to choose now and get it wrong. I realise that this might not have
been the best course of action.

Having said that, we can always go back. So, I'm open to suggestions.
I could start with only a few per arch, and then add as we see fit. My
guess is that only ARMGenRegisterInfo.inc and ARMGenSubtargetInfo.inc
would be a good start, with possibly ARMGenCallingConv.inc and
ARMGenInstrInfo.inc being the next ones to add for Clang's benefit.

That would mean separating the calls to tablegen() between
CMakeLists.txt and CMakeTblgen.txt, but that's ok.

cheers,
--renato

> On Mar 10, 2015, at 10:07 AM, Renato Golin <renato.golin at
linaro.org> wrote:
> 
> On 10 March 2015 at 16:20, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>> I’d like to avoid as much as possible adding compilation time to the
process unless it is necessary (I’m not saying it does not worth it here).
> 
> As I said in the review, it may end up being faster, because of the
> amount of crap we'll remove from all tools and LLVM.
Only if you build all those tools ;)
But yes that’s a good point overall.

>> It is not clear to me why do you need to generate *all* the table-gen
files and not only the one related to target features?
> 
> I don't know which of them yet, but I'll certainly need
CPU/FPU/ARCH
> names, register names, feature names and anything to populate a target
> description object.
> 
> I moved them all into the include file because I didn't want to have
> to choose now and get it wrong. I realise that this might not have
> been the best course of action.
> 
> Having said that, we can always go back. So, I'm open to suggestions.
> I could start with only a few per arch, and then add as we see fit. My
> guess is that only ARMGenRegisterInfo.inc and ARMGenSubtargetInfo.inc
> would be a good start, with possibly ARMGenCallingConv.inc and
> ARMGenInstrInfo.inc being the next ones to add for Clang's benefit.
> 
> That would mean separating the calls to tablegen() between
> CMakeLists.txt and CMakeTblgen.txt, but that's ok.
I just re-timed and the recent improvements Owen and Chris made to table-gen
turn the full generation of table-gen files for my out-of-tree backend from
~8min down to ~35s in debug builds, pretty nice.
At this point I’m no longer afraid about the potential compile time impact of
this change.

Thanks for working on this.

— 
Mehdi

On Tue, Mar 10, 2015 at 10:10 AM Renato Golin <renato.golin at linaro.org>
wrote:
> On 10 March 2015 at 16:20, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> > I’d like to avoid as much as possible adding compilation time to the
> process unless it is necessary (I’m not saying it does not worth it here).
>
> As I said in the review, it may end up being faster, because of the
> amount of crap we'll remove from all tools and LLVM.
>
>
> > It is not clear to me why do you need to generate *all* the table-gen
> files and not only the one related to target features?
>
> I don't know which of them yet, but I'll certainly need
CPU/FPU/ARCH
> names, register names, feature names and anything to populate a target
> description object.
>
> I moved them all into the include file because I didn't want to have
> to choose now and get it wrong. I realise that this might not have
> been the best course of action.
>
> Having said that, we can always go back. So, I'm open to suggestions.
> I could start with only a few per arch, and then add as we see fit. My
> guess is that only ARMGenRegisterInfo.inc and ARMGenSubtargetInfo.inc
> would be a good start, with possibly ARMGenCallingConv.inc and
> ARMGenInstrInfo.inc being the next ones to add for Clang's benefit.
>
> That would mean separating the calls to tablegen() between
> CMakeLists.txt and CMakeTblgen.txt, but that's ok.
>
>
Other than building it, I admit that I'm curious what sort of thing
you've
got planned for how to vend the information. Before we go further down this
path can you provide a more detailed plan here?

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/57c6268f/attachment.html>

On 10 March 2015 at 17:57, Eric Christopher <echristo at gmail.com>
wrote:
> Other than building it, I admit that I'm curious what sort of thing
you've
> got planned for how to vend the information. Before we go further down this
> path can you provide a more detailed plan here?
Oh, did I have to do anything useful with it? :)

Attached is a very crude patch where I stopped on the FPU parser.
That's when I realised that I didn't want to duplicate the tablegen
information not even once.

This patch was just me moving the ugly stuff under one common class,
but there was no way I could guarantee that the inc files would be
generated, and that would break the Clang promise of working all the
way to IR independent on which back-end is bundled with it.

I had a momentary opinion that maybe Clang didn't need to have that
promise, but when I realised that independent of that, I'd still have
to duplicate the knowledge on the fpu parser, and on the cpu parser,
and on the target info, so on and so on, it hit me that this is a lot
more than just Clang's ability to parse fpu strings.

This is the bug where I started brainstorming...

https://llvm.org/bugs/show_bug.cgi?id=20787

My idea is to have this wrapper class that will generate the target
classes (like TargetInfo, TargetMachine or whatever is needed by some
tool, future will tell), so that I don't need to duplicate them as
well. The parser will be just another accessory of such a
TargetDescription umbrella, one that Clang's front end (and the
integrated assembler, and llc, lli, etc) will use. Clang's code
generation might use TargetInfo, for example, when interpreting inline
assembly, more specifically named registers, so we can reject x86
register names when compiling for ARM.

The main problems are the difference in command line options between
clang->object and clang->IR->llc->asm->ld->object, or options
passed
down the assembler and linker (-Wa, -Wl), and how Clang and LLVM have
to be independently informed about the target capabilities.

The first step, though, will be to only have TargetParser reading the
info part and guessing cpu/fpu/arch names for the parser.

Makes sense?

cheers,
--renato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fpuparser.patch
Type: text/x-patch
Size: 13478 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/b9b89cd0/attachment.bin>