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

[Alex Wang via llvm-dev]

From: Alex Wang <aw1621107 at gmail.com>
> Date: September 28, 2015 at 4:48:29 PM EDT
> To: Chris Bieneman <beanz at apple.com>
> Subject: Re: [llvm-dev] Cmake-gen'd parallel make breaks on native tablegen
> 
>> 
>> 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/97ef5ddb/attachment.html>