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

[David Blaikie via llvm-dev]

On Tue, May 30, 2017 at 1:50 PM Zachary Turner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

Changing the header seems liable to rebuild a bunch of things that include
the header - not sure any layering changes would change that, would they?
(I don't think ninja at least waits for the library to build before
building things that include the library's headers)

Out of curiosity - what build system/linker/host compiler/OS are you using?
(& cores/ram/etc too)


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

That's why I made an equivalent change above tablegen to see what the
relative cost was - I think that's probably pretty representative. Without
tablegen touching any cpp file should (& with ninja, seems to) rebuild that
object, the library, and the resulting binary & not much/anything else.

- Dave


> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170530/3a190edf/attachment.html>