<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">There are other issues that come in WRT CMake + Xcode. We don't see a lot of people using that configuration, so we don't often discuss them.<div class=""><br class=""></div><div class="">It isn't that Xcode doesn't parallelize custom commands, it doesn't parallelize targets unless you set a setting on the scheme. CMake has limited support for generating schemes which was only added in CMake 3.9. I had briefly looked at adding scheme support to our build, but I didn't because schemes don't really match super well to LLVM development workflows, so it would really need to be added by an Xcode user wanting to define a development flow for Xcode.</div><div class=""><br class=""></div><div class="">Additionally the Xcode project format doesn't support adding custom tools in a declarative format. There are two routes that work either you embed them as shell scripts, or you wrap them in Makefiles and create Makefile build targets (CMake does the later). In either case Xcode is very limited in its ability to track dependencies in and out of shell and Makefile tasks, which frequently results in "throw hands in the air and rerun everything".</div><div class=""><br class=""></div><div class="">CMake generating Makefile targets and not having historical support for Xcode schemes combined to make the Xcode build of LLVM much slower than it should be, and there isn't really a good solution to the problem that the LLVM or CMake communities can drive.</div><div class=""><br class=""></div><div class="">-Chris<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 2, 2019, at 3:31 AM, Simon Pilgrim via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Much of this has been discussed (over many, many years) on
<a class="moz-txt-link-freetext" href="https://bugs.llvm.org/show_bug.cgi?id=28222">https://bugs.llvm.org/show_bug.cgi?id=28222</a></p><p class="">Some of the issues that were identified included:</p><p class="">1 - Poor tablegen dependency handling leading to unexpected
rebuilds.</p><p class="">2 - Debug STL iterator checks taking an insane amount of time
(might be MSVC specific).</p><p class="">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. <br class="">
</p><p class="">4 - A lot of O(N^2), or worse, code that has built up over the
years.</p><p class="">5 - Poor STL type selection resulting it excessive
iteration/access times.</p><p class="">Running a profiler every so often helps find some quick
improvements but its not really fixing these core problems.<br class="">
</p><p class="">Simon.<br class="">
</p><p class="">On 01/07/2019 21:05, Chris Bieneman via llvm-dev wrote:<br class="">
</p>
<blockquote type="cite" cite="mid:471A475C-569B-44A5-8B31-DEF3AA62D02C@me.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
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.
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">-Chris<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Jul 1, 2019, at 2:57 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="" moz-do-not-send="true">dblaikie@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">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)</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2019 at
12:54 PM Zakharin, Vyacheslav P via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="" lang="RU">
<div class="gmail-m_7961363046099572722WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="" lang="EN-US">[resending to the whole
list]</span></p><div class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="" lang="EN-US"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="" lang="EN-US">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?</span></p><div class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="" lang="EN-US"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="" lang="EN-US">Thanks,</span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class="" lang="EN-US">Slava</span></p><div class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class=""> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><a name="m_7961363046099572722__MailEndCompose" class="" moz-do-not-send="true"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" class=""> </span></a></p>
<div class="">
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt
solid rgb(225,225,225);padding:3pt 0in 0in" class=""><p class="MsoNormal"><a name="m_7961363046099572722______replyseparator" class="" moz-do-not-send="true"></a><b class=""><span style="font-size:11pt;font-family:Calibri,sans-serif" class="" lang="EN-US">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif" class="" lang="EN-US"> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev-bounces@lists.llvm.org</a>]
<b class="">On Behalf Of </b>Chris
Bieneman via llvm-dev<br class="">
<b class="">Sent:</b> Monday, July 1, 2019
10:35 AM<br class="">
<b class="">To:</b> Joan Lluch <<a href="mailto:joan.lluch@icloud.com" target="_blank" class="" moz-do-not-send="true">joan.lluch@icloud.com</a>><br class="">
<b class="">Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>><br class="">
<b class="">Subject:</b> Re: [llvm-dev]
Tablegen ridiculously slow when compiling
for Debug</span></p>
</div>
</div><div class=""> <br class="webkit-block-placeholder"></div>
<div class=""><p class="MsoNormal">Hey Joan,</p>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal">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.</p>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal">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.</p>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal">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.</p>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal">-Chris</p>
</div>
<div class=""><p class="MsoNormal" style="margin-bottom:12pt"><br class="">
On Jun 30, 2019, at 12:18 PM, Joan Lluch via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:</p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt" class="">
<div class=""><p class="MsoNormal">Hi Greg,</p>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal">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.</p>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal">John</p>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
<div class="">
<blockquote style="margin-top:5pt;margin-bottom:5pt" class="">
<div class=""><p class="MsoNormal">On 30 Jun 2019,
at 17:43, Greg Bedwell <<a href="mailto:gregbedwell@gmail.com" target="_blank" class="" moz-do-not-send="true">gregbedwell@gmail.com</a>>
wrote:</p>
</div><div class=""> <br class="webkit-block-placeholder"></div>
<div class="">
<div class="">
<div class=""><p class="MsoNormal">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.</p>
</div>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal">As previously
mentioned, the best solution is
probably to try to adjust your
workflow to use the Ninja (
</p>
<div class=""><p class="MsoNormal"><a href="https://ninja-build.org/" target="_blank" class="" moz-do-not-send="true">https://ninja-build.org</a></p>
</div><p class="MsoNormal"> ) CMake
generator if at all possible.
It's a bit of an adjustment but it
does work very nicely with the
LLVM build system.</p>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><p class="MsoNormal">-Greg</p>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
</div>
<div class="">
<div class="">
<div class=""><p class="MsoNormal">On Sun, 30
Jun 2019 at 12:08, Nicolai
Hähnle via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:</p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt
solid
rgb(204,204,204);padding:0in 0in
0in
6pt;margin-left:4.8pt;margin-right:0in" class=""><p class="MsoNormal">Are you
saying that the TableGen
execution isn't parallelized?
That
<br class="">
seems like an obvious
Xcode-specific problem...<br class="">
<br class="">
The TableGen executions are
parallelized with cmake/ninja
just fine.<br class="">
<br class="">
Cheers,<br class="">
Nicolai<br class="">
<br class="">
On 30.06.19 11:28, Joan Lluch
via llvm-dev wrote:<br class="">
> Hi Praveen,<br class="">
> <br class="">
> Thanks for the tip, but
Xcode seems to spend all the
time running <br class="">
> tablegen "custom shell
scripts", one by one at a
time, not linking. <br class="">
> Linking is actually very
fast, possibly less than a
second. The <br class="">
> “scripts” that take
longer are
“AArch64CommonTableGen" and <br class="">
> “AMDGPUCommonTableGen”.
As said this is on LLVM 9.0.<br class="">
> <br class="">
> However, on LLVM 7.0.1,
the same process takes just
5-6 seconds in <br class="">
> total, with individual
“scripts” taking significantly
less than 1 second <br class="">
> each. There must be some
difference between LLVM 9.0
and LLVM 7.0 that <br class="">
> might cause this (?)<br class="">
> <br class="">
> John<br class="">
> <br class="">
> <br class="">
>> On 30 Jun 2019, at
11:17, Praveen Velliengiri <br class="">
>> <<a href="mailto:praveenvelliengiri@gmail.com" target="_blank" class="" moz-do-not-send="true">praveenvelliengiri@gmail.com</a>
<mailto:<a href="mailto:praveenvelliengiri@gmail.com" target="_blank" class="" moz-do-not-send="true">praveenvelliengiri@gmail.com</a>>>
<br class="">
>> wrote:<br class="">
>><br class="">
>> *<br class="">
>> *<br class="">
>> cmake
*BUILD_SHARED_LIBS* option, it
builds llvm as .so not as .a.
It <br class="">
>> will use less memory
during linking so you can
increase the link <br class="">
>> threads and your
build time will be lesser.<br class="">
>> Check this in : <a href="https://llvm.org/docs/CMake.html" target="_blank" class="" moz-do-not-send="true">https://llvm.org/docs/CMake.html</a><br class="">
>><br class="">
>> **<br class="">
>> **<br class="">
>><br class="">
>> On Sun, 30 Jun 2019
at 14:42, Joan Lluch <<a href="mailto:joan.lluch@icloud.com" target="_blank" class="" moz-do-not-send="true">joan.lluch@icloud.com</a>
<br class="">
>> <mailto:<a href="mailto:joan.lluch@icloud.com" target="_blank" class="" moz-do-not-send="true">joan.lluch@icloud.com</a>>>
wrote:<br class="">
>><br class="">
>> Hi Praveen,<br class="">
>><br class="">
>> Please, can you
elaborate on this?. What do do
mean by “building<br class="">
>> as shared
objects”.<br class="">
>><br class="">
>> Thanks,<br class="">
>><br class="">
>> John<br class="">
>><br class="">
>><br class="">
>><br class="">
>>> On 30 Jun
2019, at 07:32, Praveen
Velliengiri<br class="">
>>> <<a href="mailto:praveenvelliengiri@gmail.com" target="_blank" class="" moz-do-not-send="true">praveenvelliengiri@gmail.com</a><br class="">
>>> <mailto:<a href="mailto:praveenvelliengiri@gmail.com" target="_blank" class="" moz-do-not-send="true">praveenvelliengiri@gmail.com</a>>>
wrote:<br class="">
>>><br class="">
>>> Maybe try
building llvm as a shared
objects..<br class="">
>>><br class="">
>>> On Jun 30,
2019 1:30 AM, "Joan Lluch via
llvm-dev"<br class="">
>>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>>
wrote:<br class="">
>>><br class="">
>>> Hi
Florian,<br class="">
>>><br class="">
>>> Ok, I ran
this:<br class="">
>>><br class="">
>>> cmake -S
LLVM
-DCMAKE_INSTALL_PREFIX=INSTALL<br class="">
>>>
-DLLVM_OPTIMIZED_TABLEGEN=On
-G Xcode<br class="">
>>><br class="">
>>> Compiled
it again from clean, and the
situation is worse than<br class="">
>>> before.
Incremental builds take an
incredible amount of time<br class="">
>>> stuck in
running Tablegen scripts for
all targets. Now this<br class="">
>>> happens
both in Release and Debug
configurations. Just before<br class="">
>>> this, at
least Release compiled fine,
but that’s no longer<br class="">
>>> the case.<br class="">
>>><br class="">
>>> Any other
suggestions? What could
actually cause this?<br class="">
>>><br class="">
>>> Thanks<br class="">
>>> John<br class="">
>>><br class="">
>>><br class="">
>>><br class="">
>>>> On 29
Jun 2019, at 19:37, Florian
Hahn<br class="">
>>>> <<a href="mailto:florian_hahn@apple.com" target="_blank" class="" moz-do-not-send="true">florian_hahn@apple.com</a>
<mailto:<a href="mailto:florian_hahn@apple.com" target="_blank" class="" moz-do-not-send="true">florian_hahn@apple.com</a>>>
wrote:<br class="">
>>>><br class="">
>>>> Hi,<br class="">
>>>><br class="">
>>>>>
On Jun 29, 2019, at 18:26,
Joan Lluch via llvm-dev<br class="">
>>>>>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>><br class="">
>>>>>
wrote:<br class="">
>>>>><br class="">
>>>>>
Hi all,<br class="">
>>>>><br class="">
>>>>>
On LLVM version 7.0.1,
incremental builds are very
fast for<br class="">
>>>>>
both Release and Debug. I’m
compiling with Xcode<br class="">
>>>>><br class="">
>>>>> I
recently downloaded LLVM 9.0
from the LLVM-mirror Github<br class="">
>>>>>
repository and found that
Incremental "Debug” builds
take a<br class="">
>>>>>
ridiculously long time due to
Tablegen taking ages<br class="">
>>>>>
(literally more than 10
minutes) to generate files.
This<br class="">
>>>>>
makes it totally unusable for
debug purposes. However,<br class="">
>>>>>
incremental ‘Release’ builds
only take a few seconds.<br class="">
>>>>><br class="">
>>>>>
Why is that?. Any
suggestions?.<br class="">
>>>><br class="">
>>>><br class="">
>>>><br class="">
>>>> You
could give setting
LLVM_OPTIMIZED_TABLEGEN a try<br class="">
>>>> (<a href="https://llvm.org/docs/CMake.html" target="_blank" class="" moz-do-not-send="true">https://llvm.org/docs/CMake.html</a>).<br class="">
>>>><br class="">
>>>>
Cheers,<br class="">
>>>>
Florian<br class="">
>>><br class="">
>>><br class="">
>>>
_______________________________________________<br class="">
>>> LLVM
Developers mailing list<br class="">
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>><br class="">
>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
>>><br class="">
>><br class="">
> <br class="">
> <br class="">
>
_______________________________________________<br class="">
> LLVM Developers mailing
list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br class="">
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="" moz-do-not-send="true">
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
> <br class="">
<br class="">
-- <br class="">
Lerne, wie die Welt wirklich
ist,<br class="">
Aber vergiss niemals, wie sie
sein sollte.<br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div><div class=""> <br class="webkit-block-placeholder"></div>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5pt;margin-bottom:5pt" class="">
<div class=""><p class="MsoNormal">_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></p>
</div>
</blockquote>
</div>
</div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>