Zachary Turner via llvm-dev
2017-May-30 21:28 UTC
[llvm-dev] Should we split llvm Support and ADT?
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>
Mehdi AMINI via llvm-dev
2017-May-30 21:29 UTC
[llvm-dev] Should we split llvm Support and ADT?
2017-05-30 14:28 GMT-07:00 Zachary Turner <zturner at google.com>:> 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 >If you tell it to run an external llvm-tblgen, this external tablegen becomes the producers of all the generated file. And since this external tablegen binary is not produced by your CMake, it does not depends on any source file. -- Mehdi> > 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/f6537842/attachment.html>
Zachary Turner via llvm-dev
2017-May-30 21:31 UTC
[llvm-dev] Should we split llvm Support and ADT?
But it will still re-write the output files, updating their timestamps and trigger rebuild of all dependencies (at worst) or a diff-and-noop (at best), no? Since the original proposal was about reducing the number of situations in which tablegen runs at all, I would think that the best comparison would be one in which tablegen doesn't run at all. On Tue, May 30, 2017 at 2:29 PM Mehdi AMINI <joker.eph at gmail.com> wrote:> 2017-05-30 14:28 GMT-07:00 Zachary Turner <zturner at google.com>: > >> 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 >> > > If you tell it to run an external llvm-tblgen, this external tablegen > becomes the producers of all the generated file. And since this external > tablegen binary is not produced by your CMake, it does not depends on any > source file. > > -- > Mehdi > > > > >> >> 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/9d54a89d/attachment.html>