David Blaikie via llvm-dev
2019-Jul-01 19:57 UTC
[llvm-dev] Tablegen ridiculously slow when compiling for Debug
If someone can manage it, it wouldn't be a bad thing - obviously open up more parallelism (I don't know how much of LLVM can be built before you hit everything that needs tblgen run - I guess libSupport and some other bits) On Mon, Jul 1, 2019 at 12:54 PM Zakharin, Vyacheslav P via llvm-dev < llvm-dev at lists.llvm.org> wrote:> [resending to the whole list] > > > > I wonder if we can stop rebuilding TD files unconditionally, i.e. generate > dependencies for TD files based on include directives and just allow the > build system do its job? Would that solve most of the build time issues? > > > > Thanks, > > Slava > > > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Chris > Bieneman via llvm-dev > *Sent:* Monday, July 1, 2019 10:35 AM > *To:* Joan Lluch <joan.lluch at icloud.com> > *Cc:* llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] Tablegen ridiculously slow when compiling for > Debug > > > > Hey Joan, > > > > When looking for build support it is really useful to include a bunch of > information about your build up front. Knowing that you are on macOS, and > using the Xcode generator are really useful. > > > > On macOS, BUILD_SHARED_LIBS won’t really help much because the default > linker (ld64) is pretty good. Using an IDE generator and setting > LLVM_USE_OPTIMIZED_TABLEGEN will kill your release builds. > > > > In general Xcode takes 2x-3x longer than Ninja for incremental builds, and > 1.5x-2x as long for clean builds. Lots of people use the Xcode generator to > create a project file for navigation and editing, but most people I know > doing LLVM development on macOS use Ninja for their builds. > > > > -Chris > > > On Jun 30, 2019, at 12:18 PM, Joan Lluch via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi Greg, > > > > I tried to setup Ninja before on my mac but I mush have done something > wrong and I didn’t manage to get it work. I’m not familiarised at all with > the procedures involved. I may try that again to see If I have some luck > though. It’s a pity that LLVM is not particularly friendly with familiar > IDEs such as xCode on macs and Visual Studio on windows. > > > > John > > > > On 30 Jun 2019, at 17:43, Greg Bedwell <gregbedwell at gmail.com> wrote: > > > > This is also the case with the Visual Studio generators. Custom commands > in a single cmake file essentially get written out line by line into a > single batch file that gets processed as a custom build step. In the VS > case this means that it can, for example, run X86 and Aarch64 tablegen > steps in parallel with each other but all of the individual X86 invocations > get processed serially. I can well imagine that the Xcode situation is > similar although I've no experience with it myself to know for sure. > > > > As previously mentioned, the best solution is probably to try to adjust > your workflow to use the Ninja ( > > https://ninja-build.org > > ) CMake generator if at all possible. It's a bit of an adjustment but it > does work very nicely with the LLVM build system. > > > > -Greg > > > > > > On Sun, 30 Jun 2019 at 12:08, Nicolai Hähnle via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Are you saying that the TableGen execution isn't parallelized? That > seems like an obvious Xcode-specific problem... > > The TableGen executions are parallelized with cmake/ninja just fine. > > Cheers, > Nicolai > > On 30.06.19 11:28, Joan Lluch via llvm-dev wrote: > > Hi Praveen, > > > > Thanks for the tip, but Xcode seems to spend all the time running > > tablegen "custom shell scripts", one by one at a time, not linking. > > Linking is actually very fast, possibly less than a second. The > > “scripts” that take longer are “AArch64CommonTableGen" and > > “AMDGPUCommonTableGen”. As said this is on LLVM 9.0. > > > > However, on LLVM 7.0.1, the same process takes just 5-6 seconds in > > total, with individual “scripts” taking significantly less than 1 second > > each. There must be some difference between LLVM 9.0 and LLVM 7.0 that > > might cause this (?) > > > > John > > > > > >> On 30 Jun 2019, at 11:17, Praveen Velliengiri > >> <praveenvelliengiri at gmail.com <mailto:praveenvelliengiri at gmail.com>> > >> wrote: > >> > >> * > >> * > >> cmake *BUILD_SHARED_LIBS* option, it builds llvm as .so not as .a. It > >> will use less memory during linking so you can increase the link > >> threads and your build time will be lesser. > >> Check this in : https://llvm.org/docs/CMake.html > >> > >> ** > >> ** > >> > >> On Sun, 30 Jun 2019 at 14:42, Joan Lluch <joan.lluch at icloud.com > >> <mailto:joan.lluch at icloud.com>> wrote: > >> > >> Hi Praveen, > >> > >> Please, can you elaborate on this?. What do do mean by “building > >> as shared objects”. > >> > >> Thanks, > >> > >> John > >> > >> > >> > >>> On 30 Jun 2019, at 07:32, Praveen Velliengiri > >>> <praveenvelliengiri at gmail.com > >>> <mailto:praveenvelliengiri at gmail.com>> wrote: > >>> > >>> Maybe try building llvm as a shared objects.. > >>> > >>> On Jun 30, 2019 1:30 AM, "Joan Lluch via llvm-dev" > >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >>> > >>> Hi Florian, > >>> > >>> Ok, I ran this: > >>> > >>> cmake -S LLVM -DCMAKE_INSTALL_PREFIX=INSTALL > >>> -DLLVM_OPTIMIZED_TABLEGEN=On -G Xcode > >>> > >>> Compiled it again from clean, and the situation is worse than > >>> before. Incremental builds take an incredible amount of time > >>> stuck in running Tablegen scripts for all targets. Now this > >>> happens both in Release and Debug configurations. Just before > >>> this, at least Release compiled fine, but that’s no longer > >>> the case. > >>> > >>> Any other suggestions? What could actually cause this? > >>> > >>> Thanks > >>> John > >>> > >>> > >>> > >>>> On 29 Jun 2019, at 19:37, Florian Hahn > >>>> <florian_hahn at apple.com <mailto:florian_hahn at apple.com>> > wrote: > >>>> > >>>> Hi, > >>>> > >>>>> On Jun 29, 2019, at 18:26, Joan Lluch via llvm-dev > >>>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > >>>>> wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> On LLVM version 7.0.1, incremental builds are very fast for > >>>>> both Release and Debug. I’m compiling with Xcode > >>>>> > >>>>> I recently downloaded LLVM 9.0 from the LLVM-mirror Github > >>>>> repository and found that Incremental "Debug” builds take a > >>>>> ridiculously long time due to Tablegen taking ages > >>>>> (literally more than 10 minutes) to generate files. This > >>>>> makes it totally unusable for debug purposes. However, > >>>>> incremental ‘Release’ builds only take a few seconds. > >>>>> > >>>>> Why is that?. Any suggestions?. > >>>> > >>>> > >>>> > >>>> You could give setting LLVM_OPTIMIZED_TABLEGEN a try > >>>> (https://llvm.org/docs/CMake.html). > >>>> > >>>> Cheers, > >>>> Florian > >>> > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>> > >> > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Lerne, wie die Welt wirklich ist, > Aber vergiss niemals, wie sie sein sollte. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://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/20190701/9a3825b6/attachment.html>
Chris Bieneman via llvm-dev
2019-Jul-01 20:05 UTC
[llvm-dev] Tablegen ridiculously slow when compiling for Debug
In CMake 3.7 and later the Ninja generator can handle depfiles which gives us correct and accurate dependencies for tablegen, and we do use that support if it is available. I'm surprised CMake has never extended that support to the Makefile generator, but unsurprised it isn't supported in the IDE generators. I'm reasonably confident that you can't add that support to Xcode without treating tablegen as an extra compiler, which (I believe) requires an Xcode plugin. Even if that isn't the case the Xcode build system's extensibility is largely undocumented and I'm sure it would be very challenging to extend it in this way. I think it would be possible to add that support to CMake's MSBuild generator for Visual Studio, but I'm not sure why you would. It seems like Microsoft's preferred approach to using CMake with Visual Studio is with ninja as the build tool via the CMake Server integration. -Chris> On Jul 1, 2019, at 2:57 PM, David Blaikie <dblaikie at gmail.com> wrote: > > If someone can manage it, it wouldn't be a bad thing - obviously open up more parallelism (I don't know how much of LLVM can be built before you hit everything that needs tblgen run - I guess libSupport and some other bits) > > On Mon, Jul 1, 2019 at 12:54 PM Zakharin, Vyacheslav P via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > [resending to the whole list] > > > > I wonder if we can stop rebuilding TD files unconditionally, i.e. generate dependencies for TD files based on include directives and just allow the build system do its job? Would that solve most of the build time issues? > > > > Thanks, > > Slava > > > > <> > <>From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Chris Bieneman via llvm-dev > Sent: Monday, July 1, 2019 10:35 AM > To: Joan Lluch <joan.lluch at icloud.com <mailto:joan.lluch at icloud.com>> > Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > Subject: Re: [llvm-dev] Tablegen ridiculously slow when compiling for Debug > > > > Hey Joan, > > > > When looking for build support it is really useful to include a bunch of information about your build up front. Knowing that you are on macOS, and using the Xcode generator are really useful. > > > > On macOS, BUILD_SHARED_LIBS won’t really help much because the default linker (ld64) is pretty good. Using an IDE generator and setting LLVM_USE_OPTIMIZED_TABLEGEN will kill your release builds. > > > > In general Xcode takes 2x-3x longer than Ninja for incremental builds, and 1.5x-2x as long for clean builds. Lots of people use the Xcode generator to create a project file for navigation and editing, but most people I know doing LLVM development on macOS use Ninja for their builds. > > > > -Chris > > > On Jun 30, 2019, at 12:18 PM, Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi Greg, > > > > I tried to setup Ninja before on my mac but I mush have done something wrong and I didn’t manage to get it work. I’m not familiarised at all with the procedures involved. I may try that again to see If I have some luck though. It’s a pity that LLVM is not particularly friendly with familiar IDEs such as xCode on macs and Visual Studio on windows. > > > > John > > > > On 30 Jun 2019, at 17:43, Greg Bedwell <gregbedwell at gmail.com <mailto:gregbedwell at gmail.com>> wrote: > > > > This is also the case with the Visual Studio generators. Custom commands in a single cmake file essentially get written out line by line into a single batch file that gets processed as a custom build step. In the VS case this means that it can, for example, run X86 and Aarch64 tablegen steps in parallel with each other but all of the individual X86 invocations get processed serially. I can well imagine that the Xcode situation is similar although I've no experience with it myself to know for sure. > > > > As previously mentioned, the best solution is probably to try to adjust your workflow to use the Ninja ( > > https://ninja-build.org <https://ninja-build.org/> > ) CMake generator if at all possible. It's a bit of an adjustment but it does work very nicely with the LLVM build system. > > > > -Greg > > > > > > On Sun, 30 Jun 2019 at 12:08, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Are you saying that the TableGen execution isn't parallelized? That > seems like an obvious Xcode-specific problem... > > The TableGen executions are parallelized with cmake/ninja just fine. > > Cheers, > Nicolai > > On 30.06.19 11:28, Joan Lluch via llvm-dev wrote: > > Hi Praveen, > > > > Thanks for the tip, but Xcode seems to spend all the time running > > tablegen "custom shell scripts", one by one at a time, not linking. > > Linking is actually very fast, possibly less than a second. The > > “scripts” that take longer are “AArch64CommonTableGen" and > > “AMDGPUCommonTableGen”. As said this is on LLVM 9.0. > > > > However, on LLVM 7.0.1, the same process takes just 5-6 seconds in > > total, with individual “scripts” taking significantly less than 1 second > > each. There must be some difference between LLVM 9.0 and LLVM 7.0 that > > might cause this (?) > > > > John > > > > > >> On 30 Jun 2019, at 11:17, Praveen Velliengiri > >> <praveenvelliengiri at gmail.com <mailto:praveenvelliengiri at gmail.com> <mailto:praveenvelliengiri at gmail.com <mailto:praveenvelliengiri at gmail.com>>> > >> wrote: > >> > >> * > >> * > >> cmake *BUILD_SHARED_LIBS* option, it builds llvm as .so not as .a. It > >> will use less memory during linking so you can increase the link > >> threads and your build time will be lesser. > >> Check this in : https://llvm.org/docs/CMake.html <https://llvm.org/docs/CMake.html> > >> > >> ** > >> ** > >> > >> On Sun, 30 Jun 2019 at 14:42, Joan Lluch <joan.lluch at icloud.com <mailto:joan.lluch at icloud.com> > >> <mailto:joan.lluch at icloud.com <mailto:joan.lluch at icloud.com>>> wrote: > >> > >> Hi Praveen, > >> > >> Please, can you elaborate on this?. What do do mean by “building > >> as shared objects”. > >> > >> Thanks, > >> > >> John > >> > >> > >> > >>> On 30 Jun 2019, at 07:32, Praveen Velliengiri > >>> <praveenvelliengiri at gmail.com <mailto:praveenvelliengiri at gmail.com> > >>> <mailto:praveenvelliengiri at gmail.com <mailto:praveenvelliengiri at gmail.com>>> wrote: > >>> > >>> Maybe try building llvm as a shared objects.. > >>> > >>> On Jun 30, 2019 1:30 AM, "Joan Lluch via llvm-dev" > >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> wrote: > >>> > >>> Hi Florian, > >>> > >>> Ok, I ran this: > >>> > >>> cmake -S LLVM -DCMAKE_INSTALL_PREFIX=INSTALL > >>> -DLLVM_OPTIMIZED_TABLEGEN=On -G Xcode > >>> > >>> Compiled it again from clean, and the situation is worse than > >>> before. Incremental builds take an incredible amount of time > >>> stuck in running Tablegen scripts for all targets. Now this > >>> happens both in Release and Debug configurations. Just before > >>> this, at least Release compiled fine, but that’s no longer > >>> the case. > >>> > >>> Any other suggestions? What could actually cause this? > >>> > >>> Thanks > >>> John > >>> > >>> > >>> > >>>> On 29 Jun 2019, at 19:37, Florian Hahn > >>>> <florian_hahn at apple.com <mailto:florian_hahn at apple.com> <mailto:florian_hahn at apple.com <mailto:florian_hahn at apple.com>>> wrote: > >>>> > >>>> Hi, > >>>> > >>>>> On Jun 29, 2019, at 18:26, Joan Lluch via llvm-dev > >>>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> > >>>>> wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> On LLVM version 7.0.1, incremental builds are very fast for > >>>>> both Release and Debug. I’m compiling with Xcode > >>>>> > >>>>> I recently downloaded LLVM 9.0 from the LLVM-mirror Github > >>>>> repository and found that Incremental "Debug” builds take a > >>>>> ridiculously long time due to Tablegen taking ages > >>>>> (literally more than 10 minutes) to generate files. This > >>>>> makes it totally unusable for debug purposes. However, > >>>>> incremental ‘Release’ builds only take a few seconds. > >>>>> > >>>>> Why is that?. Any suggestions?. > >>>> > >>>> > >>>> > >>>> You could give setting LLVM_OPTIMIZED_TABLEGEN a try > >>>> (https://llvm.org/docs/CMake.html <https://llvm.org/docs/CMake.html>). > >>>> > >>>> Cheers, > >>>> Florian > >>> > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > >>> > >> > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > > -- > Lerne, wie die Welt wirklich ist, > Aber vergiss niemals, wie sie sein sollte. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>_______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://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/20190701/77e2a626/attachment-0001.html>
Simon Pilgrim via llvm-dev
2019-Jul-02 08:31 UTC
[llvm-dev] Tablegen ridiculously slow when compiling for Debug
Much of this has been discussed (over many, many years) on https://bugs.llvm.org/show_bug.cgi?id=28222 Some of the issues that were identified included: 1 - Poor tablegen dependency handling leading to unexpected rebuilds. 2 - Debug STL iterator checks taking an insane amount of time (might be MSVC specific). 3 - Lack of parallelization of custom commands (XCode and VS builds) - VS at least has a recent (VS2017+?) 'build custom tools in parallel' option that can be enabled per project file - we should investigate setting that automatically. 4 - A lot of O(N^2), or worse, code that has built up over the years. 5 - Poor STL type selection resulting it excessive iteration/access times. Running a profiler every so often helps find some quick improvements but its not really fixing these core problems. Simon. On 01/07/2019 21:05, Chris Bieneman via llvm-dev wrote:> In CMake 3.7 and later the Ninja generator can handle depfiles which > gives us correct and accurate dependencies for tablegen, and we do use > that support if it is available. > > I'm surprised CMake has never extended that support to the Makefile > generator, but unsurprised it isn't supported in the IDE generators. > I'm reasonably confident that you can't add that support to Xcode > without treating tablegen as an extra compiler, which (I believe) > requires an Xcode plugin. Even if that isn't the case the Xcode build > system's extensibility is largely undocumented and I'm sure it would > be very challenging to extend it in this way. > > I think it would be possible to add that support to CMake's MSBuild > generator for Visual Studio, but I'm not sure why you would. It seems > like Microsoft's preferred approach to using CMake with Visual Studio > is with ninja as the build tool via the CMake Server integration. > > -Chris > >> On Jul 1, 2019, at 2:57 PM, David Blaikie <dblaikie at gmail.com >> <mailto:dblaikie at gmail.com>> wrote: >> >> If someone can manage it, it wouldn't be a bad thing - obviously open >> up more parallelism (I don't know how much of LLVM can be built >> before you hit everything that needs tblgen run - I guess libSupport >> and some other bits) >> >> On Mon, Jul 1, 2019 at 12:54 PM Zakharin, Vyacheslav P via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> [resending to the whole list] >> >> I wonder if we can stop rebuilding TD files unconditionally, i.e. >> generate dependencies for TD files based on include directives >> and just allow the build system do its job? Would that solve >> most of the build time issues? >> >> Thanks, >> >> Slava >> >> *From:*llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org >> <mailto:llvm-dev-bounces at lists.llvm.org>] *On Behalf Of *Chris >> Bieneman via llvm-dev >> *Sent:* Monday, July 1, 2019 10:35 AM >> *To:* Joan Lluch <joan.lluch at icloud.com >> <mailto:joan.lluch at icloud.com>> >> *Cc:* llvm-dev <llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>> >> *Subject:* Re: [llvm-dev] Tablegen ridiculously slow when >> compiling for Debug >> >> Hey Joan, >> >> When looking for build support it is really useful to include a >> bunch of information about your build up front. Knowing that you >> are on macOS, and using the Xcode generator are really useful. >> >> On macOS, BUILD_SHARED_LIBS won’t really help much because the >> default linker (ld64) is pretty good. Using an IDE generator and >> setting LLVM_USE_OPTIMIZED_TABLEGEN will kill your release builds. >> >> In general Xcode takes 2x-3x longer than Ninja for incremental >> builds, and 1.5x-2x as long for clean builds. Lots of people use >> the Xcode generator to create a project file for navigation and >> editing, but most people I know doing LLVM development on macOS >> use Ninja for their builds. >> >> -Chris >> >> >> On Jun 30, 2019, at 12:18 PM, Joan Lluch via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi Greg, >> >> I tried to setup Ninja before on my mac but I mush have done >> something wrong and I didn’t manage to get it work. I’m not >> familiarised at all with the procedures involved. I may try >> that again to see If I have some luck though. It’s a pity >> that LLVM is not particularly friendly with familiar IDEs >> such as xCode on macs and Visual Studio on windows. >> >> John >> >> On 30 Jun 2019, at 17:43, Greg Bedwell >> <gregbedwell at gmail.com <mailto:gregbedwell at gmail.com>> wrote: >> >> This is also the case with the Visual Studio generators. >> Custom commands in a single cmake file essentially get >> written out line by line into a single batch file that >> gets processed as a custom build step. In the VS case >> this means that it can, for example, run X86 and Aarch64 >> tablegen steps in parallel with each other but all of the >> individual X86 invocations get processed serially. I can >> well imagine that the Xcode situation is similar although >> I've no experience with it myself to know for sure. >> >> As previously mentioned, the best solution is probably to >> try to adjust your workflow to use the Ninja ( >> >> https://ninja-build.org <https://ninja-build.org/> >> >> ) CMake generator if at all possible. It's a bit of an >> adjustment but it does work very nicely with the LLVM >> build system. >> >> -Greg >> >> On Sun, 30 Jun 2019 at 12:08, Nicolai Hähnle via llvm-dev >> <llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Are you saying that the TableGen execution isn't >> parallelized? That >> seems like an obvious Xcode-specific problem... >> >> The TableGen executions are parallelized with >> cmake/ninja just fine. >> >> Cheers, >> Nicolai >> >> On 30.06.19 11:28, Joan Lluch via llvm-dev wrote: >> > Hi Praveen, >> > >> > Thanks for the tip, but Xcode seems to spend all >> the time running >> > tablegen "custom shell scripts", one by one at a >> time, not linking. >> > Linking is actually very fast, possibly less than a >> second. The >> > “scripts” that take longer are >> “AArch64CommonTableGen" and >> > “AMDGPUCommonTableGen”. As said this is on LLVM 9.0. >> > >> > However, on LLVM 7.0.1, the same process takes just >> 5-6 seconds in >> > total, with individual “scripts” taking >> significantly less than 1 second >> > each. There must be some difference between LLVM >> 9.0 and LLVM 7.0 that >> > might cause this (?) >> > >> > John >> > >> > >> >> On 30 Jun 2019, at 11:17, Praveen Velliengiri >> >> <praveenvelliengiri at gmail.com >> <mailto:praveenvelliengiri at gmail.com> >> <mailto:praveenvelliengiri at gmail.com >> <mailto:praveenvelliengiri at gmail.com>>> >> >> wrote: >> >> >> >> * >> >> * >> >> cmake *BUILD_SHARED_LIBS* option, it builds llvm >> as .so not as .a. It >> >> will use less memory during linking so you can >> increase the link >> >> threads and your build time will be lesser. >> >> Check this in : https://llvm.org/docs/CMake.html >> >> >> >> ** >> >> ** >> >> >> >> On Sun, 30 Jun 2019 at 14:42, Joan Lluch >> <joan.lluch at icloud.com <mailto:joan.lluch at icloud.com> >> >> <mailto:joan.lluch at icloud.com >> <mailto:joan.lluch at icloud.com>>> wrote: >> >> >> >> Hi Praveen, >> >> >> >> Please, can you elaborate on this?. What do do >> mean by “building >> >> as shared objects”. >> >> >> >> Thanks, >> >> >> >> John >> >> >> >> >> >> >> >>> On 30 Jun 2019, at 07:32, Praveen Velliengiri >> >>> <praveenvelliengiri at gmail.com >> <mailto:praveenvelliengiri at gmail.com> >> >>> <mailto:praveenvelliengiri at gmail.com >> <mailto:praveenvelliengiri at gmail.com>>> wrote: >> >>> >> >>> Maybe try building llvm as a shared objects.. >> >>> >> >>> On Jun 30, 2019 1:30 AM, "Joan Lluch via >> llvm-dev" >> >>> <llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org> >> <mailto:llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>>> wrote: >> >>> >> >>> Hi Florian, >> >>> >> >>> Ok, I ran this: >> >>> >> >>> cmake -S LLVM -DCMAKE_INSTALL_PREFIX=INSTALL >> >>> -DLLVM_OPTIMIZED_TABLEGEN=On -G Xcode >> >>> >> >>> Compiled it again from clean, and the >> situation is worse than >> >>> before. Incremental builds take an >> incredible amount of time >> >>> stuck in running Tablegen scripts for all >> targets. Now this >> >>> happens both in Release and Debug >> configurations. Just before >> >>> this, at least Release compiled fine, but >> that’s no longer >> >>> the case. >> >>> >> >>> Any other suggestions? What could >> actually cause this? >> >>> >> >>> Thanks >> >>> John >> >>> >> >>> >> >>> >> >>>> On 29 Jun 2019, at 19:37, Florian Hahn >> >>>> <florian_hahn at apple.com >> <mailto:florian_hahn at apple.com> >> <mailto:florian_hahn at apple.com >> <mailto:florian_hahn at apple.com>>> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>>> On Jun 29, 2019, at 18:26, Joan Lluch via llvm-dev >> >>>>> <llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org> >> <mailto:llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>>> >> >>>>> wrote: >> >>>>> >> >>>>> Hi all, >> >>>>> >> >>>>> On LLVM version 7.0.1, incremental builds are >> very fast for >> >>>>> both Release and Debug. I’m compiling with Xcode >> >>>>> >> >>>>> I recently downloaded LLVM 9.0 from the >> LLVM-mirror Github >> >>>>> repository and found that Incremental "Debug” >> builds take a >> >>>>> ridiculously long time due to Tablegen taking ages >> >>>>> (literally more than 10 minutes) to generate >> files. This >> >>>>> makes it totally unusable for debug purposes. >> However, >> >>>>> incremental ‘Release’ builds only take a few >> seconds. >> >>>>> >> >>>>> Why is that?. Any suggestions?. >> >>>> >> >>>> >> >>>> >> >>>> You could give setting >> LLVM_OPTIMIZED_TABLEGEN a try >> >>>> (https://llvm.org/docs/CMake.html). >> >>>> >> >>>> Cheers, >> >>>> Florian >> >>> >> >>> >> >>> _______________________________________________ >> >>> LLVM Developers mailing list >> >>> llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org> >> <mailto:llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>> >> >>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >>> >> >> >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org> >> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >> >> -- >> Lerne, wie die Welt wirklich ist, >> Aber vergiss niemals, wie sie sein sollte. >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://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/20190702/4a09cab8/attachment.html>
Zakharin, Vyacheslav P via llvm-dev
2019-Jul-03 00:19 UTC
[llvm-dev] Tablegen ridiculously slow when compiling for Debug
This is a useful piece of information, Chris! I will try it. Unfortunately, this does not help resolving Joan’s problem with Xcode. Thanks, Slava From: Chris Bieneman [mailto:chris.bieneman at me.com] Sent: Monday, July 1, 2019 1:06 PM To: David Blaikie <dblaikie at gmail.com> Cc: Zakharin, Vyacheslav P <vyacheslav.p.zakharin at intel.com>; Joan Lluch <joan.lluch at icloud.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Tablegen ridiculously slow when compiling for Debug In CMake 3.7 and later the Ninja generator can handle depfiles which gives us correct and accurate dependencies for tablegen, and we do use that support if it is available. I'm surprised CMake has never extended that support to the Makefile generator, but unsurprised it isn't supported in the IDE generators. I'm reasonably confident that you can't add that support to Xcode without treating tablegen as an extra compiler, which (I believe) requires an Xcode plugin. Even if that isn't the case the Xcode build system's extensibility is largely undocumented and I'm sure it would be very challenging to extend it in this way. I think it would be possible to add that support to CMake's MSBuild generator for Visual Studio, but I'm not sure why you would. It seems like Microsoft's preferred approach to using CMake with Visual Studio is with ninja as the build tool via the CMake Server integration. -Chris On Jul 1, 2019, at 2:57 PM, David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>> wrote: If someone can manage it, it wouldn't be a bad thing - obviously open up more parallelism (I don't know how much of LLVM can be built before you hit everything that needs tblgen run - I guess libSupport and some other bits) On Mon, Jul 1, 2019 at 12:54 PM Zakharin, Vyacheslav P via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: [resending to the whole list] I wonder if we can stop rebuilding TD files unconditionally, i.e. generate dependencies for TD files based on include directives and just allow the build system do its job? Would that solve most of the build time issues? Thanks, Slava From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Chris Bieneman via llvm-dev Sent: Monday, July 1, 2019 10:35 AM To: Joan Lluch <joan.lluch at icloud.com<mailto:joan.lluch at icloud.com>> Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: Re: [llvm-dev] Tablegen ridiculously slow when compiling for Debug Hey Joan, When looking for build support it is really useful to include a bunch of information about your build up front. Knowing that you are on macOS, and using the Xcode generator are really useful. On macOS, BUILD_SHARED_LIBS won’t really help much because the default linker (ld64) is pretty good. Using an IDE generator and setting LLVM_USE_OPTIMIZED_TABLEGEN will kill your release builds. In general Xcode takes 2x-3x longer than Ninja for incremental builds, and 1.5x-2x as long for clean builds. Lots of people use the Xcode generator to create a project file for navigation and editing, but most people I know doing LLVM development on macOS use Ninja for their builds. -Chris On Jun 30, 2019, at 12:18 PM, Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi Greg, I tried to setup Ninja before on my mac but I mush have done something wrong and I didn’t manage to get it work. I’m not familiarised at all with the procedures involved. I may try that again to see If I have some luck though. It’s a pity that LLVM is not particularly friendly with familiar IDEs such as xCode on macs and Visual Studio on windows. John On 30 Jun 2019, at 17:43, Greg Bedwell <gregbedwell at gmail.com<mailto:gregbedwell at gmail.com>> wrote: This is also the case with the Visual Studio generators. Custom commands in a single cmake file essentially get written out line by line into a single batch file that gets processed as a custom build step. In the VS case this means that it can, for example, run X86 and Aarch64 tablegen steps in parallel with each other but all of the individual X86 invocations get processed serially. I can well imagine that the Xcode situation is similar although I've no experience with it myself to know for sure. As previously mentioned, the best solution is probably to try to adjust your workflow to use the Ninja ( https://ninja-build.org<https://ninja-build.org/> ) CMake generator if at all possible. It's a bit of an adjustment but it does work very nicely with the LLVM build system. -Greg On Sun, 30 Jun 2019 at 12:08, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Are you saying that the TableGen execution isn't parallelized? That seems like an obvious Xcode-specific problem... The TableGen executions are parallelized with cmake/ninja just fine. Cheers, Nicolai On 30.06.19 11:28, Joan Lluch via llvm-dev wrote:> Hi Praveen, > > Thanks for the tip, but Xcode seems to spend all the time running > tablegen "custom shell scripts", one by one at a time, not linking. > Linking is actually very fast, possibly less than a second. The > “scripts” that take longer are “AArch64CommonTableGen" and > “AMDGPUCommonTableGen”. As said this is on LLVM 9.0. > > However, on LLVM 7.0.1, the same process takes just 5-6 seconds in > total, with individual “scripts” taking significantly less than 1 second > each. There must be some difference between LLVM 9.0 and LLVM 7.0 that > might cause this (?) > > John > > >> On 30 Jun 2019, at 11:17, Praveen Velliengiri >> <praveenvelliengiri at gmail.com<mailto:praveenvelliengiri at gmail.com> <mailto:praveenvelliengiri at gmail.com<mailto:praveenvelliengiri at gmail.com>>> >> wrote: >> >> * >> * >> cmake *BUILD_SHARED_LIBS* option, it builds llvm as .so not as .a. It >> will use less memory during linking so you can increase the link >> threads and your build time will be lesser. >> Check this in : https://llvm.org/docs/CMake.html >> >> ** >> ** >> >> On Sun, 30 Jun 2019 at 14:42, Joan Lluch <joan.lluch at icloud.com<mailto:joan.lluch at icloud.com> >> <mailto:joan.lluch at icloud.com<mailto:joan.lluch at icloud.com>>> wrote: >> >> Hi Praveen, >> >> Please, can you elaborate on this?. What do do mean by “building >> as shared objects”. >> >> Thanks, >> >> John >> >> >> >>> On 30 Jun 2019, at 07:32, Praveen Velliengiri >>> <praveenvelliengiri at gmail.com<mailto:praveenvelliengiri at gmail.com> >>> <mailto:praveenvelliengiri at gmail.com<mailto:praveenvelliengiri at gmail.com>>> wrote: >>> >>> Maybe try building llvm as a shared objects.. >>> >>> On Jun 30, 2019 1:30 AM, "Joan Lluch via llvm-dev" >>> <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>> wrote: >>> >>> Hi Florian, >>> >>> Ok, I ran this: >>> >>> cmake -S LLVM -DCMAKE_INSTALL_PREFIX=INSTALL >>> -DLLVM_OPTIMIZED_TABLEGEN=On -G Xcode >>> >>> Compiled it again from clean, and the situation is worse than >>> before. Incremental builds take an incredible amount of time >>> stuck in running Tablegen scripts for all targets. Now this >>> happens both in Release and Debug configurations. Just before >>> this, at least Release compiled fine, but that’s no longer >>> the case. >>> >>> Any other suggestions? What could actually cause this? >>> >>> Thanks >>> John >>> >>> >>> >>>> On 29 Jun 2019, at 19:37, Florian Hahn >>>> <florian_hahn at apple.com<mailto:florian_hahn at apple.com> <mailto:florian_hahn at apple.com<mailto:florian_hahn at apple.com>>> wrote: >>>> >>>> Hi, >>>> >>>>> On Jun 29, 2019, at 18:26, Joan Lluch via llvm-dev >>>>> <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>> >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> On LLVM version 7.0.1, incremental builds are very fast for >>>>> both Release and Debug. I’m compiling with Xcode >>>>> >>>>> I recently downloaded LLVM 9.0 from the LLVM-mirror Github >>>>> repository and found that Incremental "Debug” builds take a >>>>> ridiculously long time due to Tablegen taking ages >>>>> (literally more than 10 minutes) to generate files. This >>>>> makes it totally unusable for debug purposes. However, >>>>> incremental ‘Release’ builds only take a few seconds. >>>>> >>>>> Why is that?. Any suggestions?. >>>> >>>> >>>> >>>> You could give setting LLVM_OPTIMIZED_TABLEGEN a try >>>> (https://llvm.org/docs/CMake.html). >>>> >>>> Cheers, >>>> Florian >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://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/20190703/f340f08b/attachment.html>