llvm dev - May 2017 - Should we split llvm Support and ADT?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170530/bd3ccfb6/attachment.html>

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>

ninja, MSVC compiler, MSVC linker, Windows 10, 48 logical cores, 64GB ram.

On Tue, May 30, 2017 at 2:00 PM David Blaikie <dblaikie at gmail.com>
wrote:
> 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/79fe0ec5/attachment-0001.html>

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/c6676947/attachment.html>

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>

---- On Tue, 30 May 2017 13:50:13 -0700 Zachary Turner <zturner at
google.com> 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.






Zach already mentioned that he really wants to focus on Support rather than
tablegen, but I gathered some numbers so I figured I might as well share them. I
did a few builds on Windows 10 with Clang as the compiler and link.exe as the
linker (so not the exact same configuration as Zach, who was using the MSVC
compiler). Here are the numbers:

Debug build with LLVM_OPTIMIZED_TABLEGEN=off:

clean build: about 10 minutes
rebuild after raw_ostream change: about 100 seconds

Debug build with LLVM_OPTIMIZED_TABLEGEN=on:

clean build: about 10 minutes
rebuild after raw_ostream change: about 50 seconds

RelWithDebInfo + asserts build with LLVM_OPTIMIZED_TABLEGEN=off:

clean build: about 9 minutes
rebuild after raw_ostream change: about 20 seconds

We can see that using a Debug version of tablegen really slows things down a
lot. We go from 50 seconds to 100 seconds. And the 50 seconds already includes
building tablegen's dependencies twice - one optimized version for the
optimized tablegen, and one debug version for the rest of the build.

My understanding is that we rebuild and re-run tablegen in response to changes
in Support, and so this would re-run tablegen for everything, conclude that the
generated files are the same as the previously generated files, and not
overwrite the generated files. In other words, a build on the same hardware and
OS that takes 5 or 10 minutes isn't spending more time in tablegen than the
100-second build I did, and so spends most of its time doing things that are not
tablegen.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170530/79833d8a/attachment.html>