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

Renato Golin renato.golin at linaro.org
Thu Mar 12 15:22:46 PDT 2015

Gentle ping?

On 10 March 2015 at 18:45, Renato Golin <renato.golin at linaro.org> wrote:
> 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

More information about the llvm-dev mailing list