llvm dev - Oct 2015 - Cmake-gen'd parallel make breaks on native tablegen

Hello backend devs,

Been working on a parallelization bug in the cmake configs, where parallel
makefile builds of llvm with clang and native tablegen would usually break
during linking in either either the clang_tblgen or llvm_tblgen targets. Looking
at the cmake command that generates the tablegen makefile commands (I think)
(cmake/modules/TableGen.cmake:113-117):

      add_custom_command(OUTPUT ${${project}_TABLEGEN_EXE}
        COMMAND ${CMAKE_COMMAND} --build ../.. --target ${target} --config
Release
        DEPENDS CONFIGURE_LLVM_NATIVE ${target}
        WORKING_DIRECTORY ${LLVM_NATIVE_BUILD}
        COMMENT "Building native TableGen...")

My guess is that the clang and llvm tablegen builds are trying to place their
output into the same folder, so depending on when the resulting library gets
linked/moved one of the threads could be left dangling with a
partially-completed library or no library. The error was either
"Couldn't stat output file: ../LLVMSupport.a No such file or
directory" or something about an archive member extending past the end of
the file, and the cmake progress messages before linking were printed twice.
Once for each thread, I'd guess? Sort of surprised that they seem to share
so much code (or at least filenames)

First thing I could think of to fix this is adding another layer or two of
CMakeLists, so the tablegen creation command would be invoked in different
folders. I'm not convinced that that is the best fix, and I couldn't
figure out how to move the builds into different folders with only minor changes
to the existing cmake files.

Thoughts?

-Alex

(CrossCompile.cmake also has a typo in the first line: "toochain"
--> "toolchain", if that is something to worry about)

> On Sep 28, 2015, at 12:07 PM, Alex Wang via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hello backend devs,
> 
> Been working on a parallelization bug in the cmake configs, where parallel
makefile builds of llvm with clang and native tablegen would usually break
during linking in either either the clang_tblgen or llvm_tblgen targets. Looking
at the cmake command that generates the tablegen makefile commands (I think)
(cmake/modules/TableGen.cmake:113-117):
> 
>      add_custom_command(OUTPUT ${${project}_TABLEGEN_EXE}
>        COMMAND ${CMAKE_COMMAND} --build ../.. --target ${target} --config
Release
>        DEPENDS CONFIGURE_LLVM_NATIVE ${target}
>        WORKING_DIRECTORY ${LLVM_NATIVE_BUILD}
>        COMMENT "Building native TableGen...")
> 
> My guess is that the clang and llvm tablegen builds are trying to place
their output into the same folder, so depending on when the resulting library
gets linked/moved one of the threads could be left dangling with a
partially-completed library or no library.
If you build with LLVM_OPTIMIZED_TABLEGEN the native tablegen is a fully
generated build subtree. Make seems to have some problems with thread scheduling
with these builds. I haven’t diagnosed the issue, but it isn’t that the builds
are writing to the same directory. It happens regardless of whether you’re
building llvm with or without clang, and the llvm & clang tablegen
executables are named differently so they don’t conflict.
> The error was either "Couldn't stat output file: ../LLVMSupport.a
No such file or directory" or something about an archive member extending
past the end of the file, and the cmake progress messages before linking were
printed twice. Once for each thread, I'd guess? Sort of surprised that they
seem to share so much code (or at least filenames)
> 
> First thing I could think of to fix this is adding another layer or two of
CMakeLists, so the tablegen creation command would be invoked in different
folders. I'm not convinced that that is the best fix, and I couldn't
figure out how to move the builds into different folders with only minor changes
to the existing cmake files.
I don’t think that will work. As I said above, they are building to different
directories. You can note that in the custom command setting WORKING_DIRECTORY
to ${LLVM_NATIVE_BUILD}, which is a nested fully-independent cmake build tree.

-Chris
> 
> Thoughts?
> 
> -Alex
> 
> (CrossCompile.cmake also has a typo in the first line: "toochain"
--> "toolchain", if that is something to worry about)
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

That sounds much more reasonable than more directories. I'll see if I
can't hack something together...

I still think you have a point; I would have expected cmake to catch that
dependency. Strange thing is that just that library had an independent cmake
build going, with different percents showing and not being verbose when the main
config had it on.

-Alex
> On Sep 28, 2015, at 5:02 PM, Chris Bieneman <beanz at apple.com>
wrote:
> 
> I think I understand what you think the issue is. I would have assumed that
the generated makefiles could handle two targets building simultaneously, but
you may be right.
> 
> I don’t think we should solve this with separate directories though because
that is a waste. A better solution would be making a custom command & target
that builds the native libSupport, then make all tablegen targets depend on that
one.
> 
> That way we only build the native libSupport once.
> 
> -Chris
> 
>> On Sep 28, 2015, at 1:48 PM, Alex Wang <aw1621107 at gmail.com
<mailto:aw1621107 at gmail.com>> wrote:
>> 
>>> 
>>> On Sep 28, 2015, at 3:56 PM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>>> 
>>>> 
>>>> On Sep 28, 2015, at 12:07 PM, Alex Wang via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>>> 
>>>> Hello backend devs,
>>>> 
>>>> Been working on a parallelization bug in the cmake configs,
where parallel makefile builds of llvm with clang and native tablegen would
usually break during linking in either either the clang_tblgen or llvm_tblgen
targets. Looking at the cmake command that generates the tablegen makefile
commands (I think) (cmake/modules/TableGen.cmake:113-117):
>>>> 
>>>>     add_custom_command(OUTPUT ${${project}_TABLEGEN_EXE}
>>>>       COMMAND ${CMAKE_COMMAND} --build ../.. --target ${target}
--config Release
>>>>       DEPENDS CONFIGURE_LLVM_NATIVE ${target}
>>>>       WORKING_DIRECTORY ${LLVM_NATIVE_BUILD}
>>>>       COMMENT "Building native TableGen...")
>>>> 
>>>> My guess is that the clang and llvm tablegen builds are trying
to place their output into the same folder, so depending on when the resulting
library gets linked/moved one of the threads could be left dangling with a
partially-completed library or no library.
>>> 
>>> If you build with LLVM_OPTIMIZED_TABLEGEN the native tablegen is a
fully generated build subtree. Make seems to have some problems with thread
scheduling with these builds. I haven’t diagnosed the issue, but it isn’t that
the builds are writing to the same directory. It happens regardless of whether
you’re building llvm with or without clang, and the llvm & clang tablegen
executables are named differently so they don’t conflict.
>> 
>> Hmmm, that's odd. I never saw the build break like this when
building only llvm. Seems I just got really (un)lucky...
>> 
>> Probably could have explained this better... It wasn't that I
thought the output executables would clash; I thought that both the llvm and
clang tablegen builds were working on libLLVMSupport at the same time in the
same place, so when one finished and moved the library to its proper place the
other thread is left without anything to work with. Seems like what you said
would still apply though.
>> 
>> Another thing to note is that when building with clang the cmake
percentages for that particular library would always go above 100%. I thought
that meant that they could be writing to the same progress file, because that
never happened with llvm-only builds.
>> 
>>>> The error was either "Couldn't stat output file:
../LLVMSupport.a No such file or directory" or something about an archive
member extending past the end of the file, and the cmake progress messages
before linking were printed twice. Once for each thread, I'd guess? Sort of
surprised that they seem to share so much code (or at least filenames)
>>>> 
>>>> First thing I could think of to fix this is adding another
layer or two of CMakeLists, so the tablegen creation command would be invoked in
different folders. I'm not convinced that that is the best fix, and I
couldn't figure out how to move the builds into different folders with only
minor changes to the existing cmake files.
>>> 
>>> I don’t think that will work. As I said above, they are building to
different directories. You can note that in the custom command setting
WORKING_DIRECTORY to ${LLVM_NATIVE_BUILD}, which is a nested fully-independent
cmake build tree.
>>> 
>> 
>> At least on my machine, ${LLVM_NATIVE_BUILD} is the same for both llvm
and clang tablegen commands.
>>> 
>>> 
>>>> 
>>>> Thoughts?
>>>> 
>>>> -Alex
>>>> 
>>>> (CrossCompile.cmake also has a typo in the first line:
"toochain" --> "toolchain", if that is something to worry
about)
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/20150928/a2c15283/attachment.html>

Alright, got something thrown together. Here it is inline (also attached if
that's more convenient):

diff --git a/cmake/modules/TableGen.cmake b/cmake/modules/TableGen.cmake
index 452a728..be6729d 100644
--- a/cmake/modules/TableGen.cmake
+++ b/cmake/modules/TableGen.cmake
@@ -107,9 +107,18 @@ macro(add_tablegen target project)
       endif()
       set(${project}_TABLEGEN_EXE ${${project}_TABLEGEN_EXE} PARENT_SCOPE)
 
+      if(NOT TARGET NATIVE_LIB_LLVMSUPPORT)
+        add_custom_command(OUTPUT LIB_LLVMSUPPORT
+          COMMAND ${CMAKE_COMMAND} --build . --target LLVMSupport --config
Release
+          DEPENDS CONFIGURE_LLVM_NATIVE
+          WORKING_DIRECTORY ${LLVM_NATIVE_BUILD}
+          COMMENT "Building libLLVMSupport for native TableGen...")
+        add_custom_target(NATIVE_LIB_LLVMSUPPORT DEPENDS LIB_LLVMSUPPORT)
+      endif(NOT TARGET NATIVE_LIB_LLVMSUPPORT)
+
       add_custom_command(OUTPUT ${${project}_TABLEGEN_EXE}
         COMMAND ${CMAKE_COMMAND} --build . --target ${target} --config Release
-        DEPENDS CONFIGURE_LLVM_NATIVE ${target}
+        DEPENDS ${target} NATIVE_LIB_LLVMSUPPORT
         WORKING_DIRECTORY ${LLVM_NATIVE_BUILD}
         COMMENT "Building native TableGen...")
       add_custom_target(${project}-tablegen-host DEPENDS
${${project}_TABLEGEN_EXE})

Basically does exactly what Chris suggested: Make a custom command + target just
for the native libLLVMSupport, and have the existing stuff depend on that.

I don't really like having to check to see if NATIVE_LIB_LLVMSUPPORT is
already defined as a target, but I'm not sure what else to do. It looks like
this particular macro is called multiple times, and I don't think defining
this elsewhere wouldn't be very good because it's only used here. It
shouldn't have a significant effect, though, because the cmake prep is so
short compared to the actual build.

-Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: TableGen.cmake.patch
Type: application/octet-stream
Size: 1208 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151004/a7ba00bb/attachment.obj>
-------------- next part --------------
> On Sep 28, 2015, at 5:19 PM, Alex Wang <aw1621107 at gmail.com>
wrote:
> 
> That sounds much more reasonable than more directories. I'll see if I
can't hack something together...
> 
> I still think you have a point; I would have expected cmake to catch that
dependency. Strange thing is that just that library had an independent cmake
build going, with different percents showing and not being verbose when the main
config had it on.
> 
> -Alex
> 
>> On Sep 28, 2015, at 5:02 PM, Chris Bieneman <beanz at apple.com>
wrote:
>> 
>> I think I understand what you think the issue is. I would have assumed
that the generated makefiles could handle two targets building simultaneously,
but you may be right.
>> 
>> I don’t think we should solve this with separate directories though
because that is a waste. A better solution would be making a custom command
& target that builds the native libSupport, then make all tablegen targets
depend on that one.
>> 
>> That way we only build the native libSupport once.
>> 
>> -Chris
>> 
>>> On Sep 28, 2015, at 1:48 PM, Alex Wang <aw1621107 at
gmail.com> wrote:
>>> 
>>>> 
>>>> On Sep 28, 2015, at 3:56 PM, Chris Bieneman <beanz at
apple.com> wrote:
>>>> 
>>>>> 
>>>>> On Sep 28, 2015, at 12:07 PM, Alex Wang via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>>> 
>>>>> Hello backend devs,
>>>>> 
>>>>> Been working on a parallelization bug in the cmake configs,
where parallel makefile builds of llvm with clang and native tablegen would
usually break during linking in either either the clang_tblgen or llvm_tblgen
targets. Looking at the cmake command that generates the tablegen makefile
commands (I think) (cmake/modules/TableGen.cmake:113-117):
>>>>> 
>>>>>     add_custom_command(OUTPUT ${${project}_TABLEGEN_EXE}
>>>>>       COMMAND ${CMAKE_COMMAND} --build ../.. --target
${target} --config Release
>>>>>       DEPENDS CONFIGURE_LLVM_NATIVE ${target}
>>>>>       WORKING_DIRECTORY ${LLVM_NATIVE_BUILD}
>>>>>       COMMENT "Building native TableGen...")
>>>>> 
>>>>> My guess is that the clang and llvm tablegen builds are
trying to place their output into the same folder, so depending on when the
resulting library gets linked/moved one of the threads could be left dangling
with a partially-completed library or no library.
>>>> 
>>>> If you build with LLVM_OPTIMIZED_TABLEGEN the native tablegen
is a fully generated build subtree. Make seems to have some problems with thread
scheduling with these builds. I haven’t diagnosed the issue, but it isn’t that
the builds are writing to the same directory. It happens regardless of whether
you’re building llvm with or without clang, and the llvm & clang tablegen
executables are named differently so they don’t conflict.
>>> 
>>> Hmmm, that's odd. I never saw the build break like this when
building only llvm. Seems I just got really (un)lucky...
>>> 
>>> Probably could have explained this better... It wasn't that I
thought the output executables would clash; I thought that both the llvm and
clang tablegen builds were working on libLLVMSupport at the same time in the
same place, so when one finished and moved the library to its proper place the
other thread is left without anything to work with. Seems like what you said
would still apply though.
>>> 
>>> Another thing to note is that when building with clang the cmake
percentages for that particular library would always go above 100%. I thought
that meant that they could be writing to the same progress file, because that
never happened with llvm-only builds.
>>> 
>>>>> The error was either "Couldn't stat output file:
../LLVMSupport.a No such file or directory" or something about an archive
member extending past the end of the file, and the cmake progress messages
before linking were printed twice. Once for each thread, I'd guess? Sort of
surprised that they seem to share so much code (or at least filenames)
>>>>> 
>>>>> First thing I could think of to fix this is adding another
layer or two of CMakeLists, so the tablegen creation command would be invoked in
different folders. I'm not convinced that that is the best fix, and I
couldn't figure out how to move the builds into different folders with only
minor changes to the existing cmake files.
>>>> 
>>>> I don’t think that will work. As I said above, they are
building to different directories. You can note that in the custom command
setting WORKING_DIRECTORY to ${LLVM_NATIVE_BUILD}, which is a nested
fully-independent cmake build tree.
>>>> 
>>> 
>>> At least on my machine, ${LLVM_NATIVE_BUILD} is the same for both
llvm and clang tablegen commands.
>>>> 
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> -Alex
>>>>> 
>>>>> (CrossCompile.cmake also has a typo in the first line:
"toochain" --> "toolchain", if that is something to worry
about)
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>