thr3ads.net - llvm dev - [llvm-dev] [PATCH] Cmake-gen'd parallel make breaks on native tablegen [Oct 2015]

If this information is useful, please help other people find it:
Share via:

Alex Wang via llvm-dev

2015-Oct-05 00:20 UTC

[llvm-dev] Cmake-gen'd parallel make breaks on native tablegen

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
>> 
>

Alex Wang via llvm-dev

2015-Oct-05 16:37 UTC

head link

[llvm-dev] Cmake-gen'd parallel make breaks on native tablegen

Probably should have checked earlier... Do patches go directly to llvm-commits
for review instead of getting reviewed here first?

ccing llvm-commits too in case> On Oct 4, 2015, at 8:20 PM, Alex Wang <aw1621107 at gmail.com> wrote:
> 
> 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
> 
> <TableGen.cmake.patch>
>> 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
>>> 
>> 
>

Alex Wang via llvm-dev

2015-Oct-05 16:41 UTC

head link

[llvm-dev] [PATCH] Cmake-gen'd parallel make breaks on native tablegen

Probably should have checked earlier... Do patches resulting from conversations
here go directly to llvm-commits for review?

ccing llvm-commits too in case> On Oct 4, 2015, at 8:20 PM, Alex Wang <aw1621107 at gmail.com> wrote:
> 
> 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
> 
> <TableGen.cmake.patch>
>> 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
>>> 
>> 
>

Chris Bieneman via llvm-dev

2015-Oct-06 23:58 UTC

head link

[llvm-dev] Cmake-gen'd parallel make breaks on native tablegen

> On Oct 5, 2015, at 9:37 AM, Alex Wang via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Probably should have checked earlier... Do patches go directly to
llvm-commits for review instead of getting reviewed here first?
> 
> ccing llvm-commits too in case
>> On Oct 4, 2015, at 8:20 PM, Alex Wang <aw1621107 at gmail.com>
wrote:
>> 
>> 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)
Instead of doing this you could move creating this out of the macro. Then it
will be executed when the file is included which should only be once.
>> +        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
>> 
>> <TableGen.cmake.patch>
>>> 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
>>>> 
>>> 
>> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

[llvm-dev] Cmake-gen'd parallel make breaks on native tablegen

[llvm-dev] Cmake-gen'd parallel make breaks on native tablegen

[llvm-dev] [PATCH] Cmake-gen'd parallel make breaks on native tablegen

[llvm-dev] Cmake-gen'd parallel make breaks on native tablegen