[llvm-dev] Should we split llvm Support and ADT?

Zachary Turner via llvm-dev llvm-dev at lists.llvm.org
Tue May 30 14:28:11 PDT 2017


Doesn't that just tell it what tablegen to use?  I was looking for an
option to make it not run *anything*, and just assume that all tablegen
definitions were up to date

On Tue, May 30, 2017 at 2:27 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

> 2017-05-30 13:50 GMT-07:00 Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>>
>>
>> On Tue, May 30, 2017 at 12:52 PM Bob Haarman <llvm at inglorion.net> wrote:
>>
>>> I would like to better understand how you came to conclude that the
>>> tablegen re-runs based on changes in Support are what's causing your build
>>> to be slow and what part specifically is taking all that time. I can do a
>>> clean release + assertions build of LLVM, Clang, compiler-rt and lld in
>>> about 5 minutes, plus 40 seconds to run cmake, on what I think is similar
>>> hardware to what Zach is using. If I swap Ptr += ret and Size -= Ret in
>>> raw_fd_ostream::write_impl so that Support changes, I can do an incremental
>>> build in about 10 seconds, including the regeneration of various .inc
>>> files. How do we get from there to 10 minutes for an incremental build?
>>>
>>
>> For the sake of comparison, I made the same change and it took  1:58.39.
>> A slightly different but more intrusive change to Format.h in
>> format_object_base::print() took 5:6.54.  A clean build on the same machine
>> takes about 12 minutes.
>>
>> I tried a few hacks to the CMake to say "don't run tablegen, no matter
>> what, and don't make anything depend on tablegen's output", but I couldn't
>> come up with the right magic.  If anyone knows, I can test a side-by-side
>> comparison without tablegen.
>>
>
> I mentioned earlier in the thread that there is already a CMake option for
> this: -DLLVM_TABLEGEN=path/to/llvm-tblgen
>
>
> --
> Mehdi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170530/332f7d92/attachment.html>


More information about the llvm-dev mailing list