<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Mar 10, 2015 at 10:10 AM Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10 March 2015 at 16:20, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>> wrote:<br>
> 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).<br>
<br>
As I said in the review, it may end up being faster, because of the<br>
amount of crap we'll remove from all tools and LLVM.<br>
<br>
<br>
> 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?<br>
<br>
I don't know which of them yet, but I'll certainly need CPU/FPU/ARCH<br>
names, register names, feature names and anything to populate a target<br>
description object.<br>
<br>
I moved them all into the include file because I didn't want to have<br>
to choose now and get it wrong. I realise that this might not have<br>
been the best course of action.<br>
<br>
Having said that, we can always go back. So, I'm open to suggestions.<br>
I could start with only a few per arch, and then add as we see fit. My<br>
guess is that only ARMGenRegisterInfo.inc and ARMGenSubtargetInfo.inc<br>
would be a good start, with possibly ARMGenCallingConv.inc and<br>
ARMGenInstrInfo.inc being the next ones to add for Clang's benefit.<br>
<br>
That would mean separating the calls to tablegen() between<br>
CMakeLists.txt and CMakeTblgen.txt, but that's ok.<br><br></blockquote><div><br></div><div>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?</div><div><br></div><div>-eric</div></div></div>