[LLVMdev] TargetParser - Always build all table-gen files?

[Renato Golin]

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>