[llvm-commits] [llvm] r136023 - in /llvm/trunk: cmake/modules/ lib/Target/ARM/ lib/Target/ARM/AsmParser/ lib/Target/ARM/Disassembler/ lib/Target/ARM/InstPrinter/ lib/Target/ARM/MCTargetDesc/ lib/Target/Alpha/ lib/Target/Alpha/MCTargetDesc/ lib/Target/Alpha/Targ

[Chandler Carruth]

On Mon, Jul 25, 2011 at 7:18 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:

> Chandler Carruth <chandlerc at google.com> writes:
>
> >> I'm not sure I get this. Previous to your change, the LLVM library
> >> (LLVMX86CodeGen, for instance) had LLVMX86CodeGen_TableGen as a
> >> dependency (plus the tablegen source files) and its sublibraries
> >> (LLVMX86AsmPrinter, ...) had LLVMX86CodeGen as a dependency.
> >
> > This is source of the confusion. The sublibraries no longer (in many
> cases)
> > depend on LLVMX86CodeGen; specifically MCTargetDesc actively avoids such
> a
> > dependency.
>
> This is tangential. What I'm trying to say is that the sublibrary is not
> built until the top library finishes building, which means that
> tablegenning is done. If the sublibrary references symbols defined by
> the top library (or the tablegenned files) that's a different topic.
>

I'm not sure what platform your observe this behavior, but I don't observe
it on Linux. I specifically observe the opposing behavior: subdirectories
which do not depend on the libraries in the parent directory are started in
parallel. This is one of the advantage of CMake; the builds are highly
parallel because of this eager descent into subdirectories.

>> Somehow
> >> this didn't work. So why do we need add_public_tablegen_target at all?
> >> The sublibraries, by depending on LLVMX86CodeGen, should not start
> >> building until after LLVMX86CodeGen is created, which means that the
> >> tablegenning is finished too.
> >
> > See above. The dependency that previously existed no longer does. Thus
> the
> > need for a specific one for the only actual sharing between these two:
> the
> > tablegen files.
>
> This means an optimization for parallel builds, but doesn't make the
> build any more robust.


I specifically, repeatedly saw the tablegen actions fail to be performed
prior to the build and analysis of the subdirectory, so I do in fact find it
makes it more robust... I'm sorry if you can't reproduce this, but I did
several times, and confirmed with other CMake users.

The problem with explicitly stating the dependency on every sub-library
> is that the writer must decide if the dependency actually exists or not
> (and keep the decission up to date as changes are made to the
> libraries.) And he has a lot of room for making a mistake. A failed
> dependency on this scenario is, essentially, a heisenbug. Personally, I
> prefer a global conservative rule.
>

I don't really follow either of these paths of reasoning.

First, I do expect authors of code to actively think about and maintain the
dependencies of their code. LLVM has actually paid a dear price for not
doing this, see Evans heroic work to re-separate the MC and Target layers.
Developers are not left without tools here: the build should actually break
if they forget to update the dependencies. I would be very interested in
tightening this up so that the build *always* breaks when dependencies are
mis-specified rather than merely becoming unreliable.


BTW, possibly not related but the build is failing with:
>

This looks like a missing dependency in MSP430Desc. I can look into it.

I'd like to point out however that all of our "automatic" management of
dependencies didn't help here; we still have failures and still have to
debug them by hand. Given that, its hard for me to argue that they are
saving us from all of the manual work of maintaining dependencies.


>
> Linking CXX executable ../../bin/llvm-mc
> ../../lib/libLLVMMSP430Desc.a(MSP430MCTargetDesc.cpp.o): In function
> `createMSP430MCInstPrinter(llvm::Target const&, unsigned int,
> llvm::MCAsmInfo const&)':
> MSP430MCTargetDesc.cpp:(.text+0x18d): undefined reference to `vtable for
> llvm::MSP430InstPrinter'
> ../../lib/libLLVMMipsDesc.a(MipsMCTargetDesc.cpp.o): In function
> `createMipsMCInstPrinter(llvm::Target const&, unsigned int, llvm::MCAsmInfo
> const&)':
> MipsMCTargetDesc.cpp:(.text+0x421): undefined reference to `vtable for
> llvm::MipsInstPrinter'
> ../../lib/libLLVMPowerPCDesc.a(PPCMCTargetDesc.cpp.o): In function
> `createPPCMCInstPrinter(llvm::Target const&, unsigned int, llvm::MCAsmInfo
> const&)':
> PPCMCTargetDesc.cpp:(.text+0x330): undefined reference to `vtable for
> llvm::PPCInstPrinter'
> ../../lib/libLLVMARMDesc.a(ARMMCTargetDesc.cpp.o): In function
> `createARMMCInstPrinter(llvm::Target const&, unsigned int, llvm::MCAsmInfo
> const&)':
> ARMMCTargetDesc.cpp:(.text+0x32d): undefined reference to `vtable for
> llvm::ARMInstPrinter'
> ../../lib/libLLVMMBlazeDesc.a(MBlazeMCTargetDesc.cpp.o): In function
> `createMBlazeMCInstPrinter(llvm::Target const&, unsigned int,
> llvm::MCAsmInfo const&)':
> MBlazeMCTargetDesc.cpp:(.text+0x2ad): undefined reference to `vtable for
> llvm::MBlazeInstPrinter'
> collect2: ld returned 1 exit status
> make[2]: *** [bin/llvm-mc] Error 1
> make[1]: *** [tools/llvm-mc/CMakeFiles/llvm-mc.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110725/06cdee3e/attachment.html>