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

Mehdi Amini mehdi.amini at apple.com
Tue Mar 10 10:27:19 PDT 2015

> 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.


More information about the llvm-dev mailing list