[llvm] r296850 - Revert r296730, "cmake: Configure the ThinLTO cache directory when using ELF lld or gold."
Peter Collingbourne via llvm-commits
llvm-commits at lists.llvm.org
Thu Mar 2 18:58:23 PST 2017
I managed to reproduce the problem locally, and I am still debugging it,
but it appears that linking certain binaries (llvm-c-test at least) causes
us to create different objects with the same key in some cases.
My suspicion is that we are failing to include prevailing symbol
information in the hash.
If I use a separate cache directory for each binary and I diff the symbol
tables of the differing objects in the cache directories for llvm-c-test
and llvm-dwp they all look like this:
@@ -16,7 +16,7 @@
U
__PRETTY_FUNCTION__._ZN4llvm18PointerIntPairInfoIPvLj1ENS_22PointerUnionUIntTraitsIPKNS_5ValueEPKNS_17PseudoSourceValueEEEE13updatePointerElS1_.llvm.B5105C7D
U
__PRETTY_FUNCTION__._ZN4llvm18TargetRegisterInfo17isVirtualRegisterEj.llvm.1C4EFC58
U
__PRETTY_FUNCTION__._ZN4llvm18TargetRegisterInfo17isVirtualRegisterEj.llvm.C4B43FD1
- U
__PRETTY_FUNCTION__._ZN4llvm19MachineRegisterInfo20defusechain_iteratorILb0ELb1ELb0ELb1ELb0ELb0EE7advanceEv.llvm.C4B43FD1
+ U
__PRETTY_FUNCTION__._ZN4llvm19MachineRegisterInfo20defusechain_iteratorILb0ELb1ELb0ELb1ELb0ELb0EE7advanceEv.llvm.1C4EFC58
U
__PRETTY_FUNCTION__._ZN4llvm19MachineRegisterInfo20getNextOperandForRegEPKNS_14MachineOperandE.llvm.1C4EFC58
U
__PRETTY_FUNCTION__._ZN4llvm19MachineRegisterInfo20getNextOperandForRegEPKNS_14MachineOperandE.llvm.C4B43FD1
U
__PRETTY_FUNCTION__._ZN4llvm19MachineRegisterInfo20getNextOperandForRegEPKNS_14MachineOperandE.llvm.CD79E700
@@ -31,6 +31,7 @@
U
__PRETTY_FUNCTION__._ZNK4llvm14ilist_iteratorINS_12ilist_detail12node_optionsINS_12MachineInstrELb1ELb1EvEELb0ELb0EEdeEv.llvm.EEBE0BEA
U
__PRETTY_FUNCTION__._ZNK4llvm14MachineOperand5isDefEv.llvm.1C4EFC58
U
__PRETTY_FUNCTION__._ZNK4llvm14MachineOperand5isDefEv.llvm.CD79E700
+ U
__PRETTY_FUNCTION__._ZNK4llvm14MachineOperand5isUseEv.llvm.1C4EFC58
U
__PRETTY_FUNCTION__._ZNK4llvm14MachineOperand5isUseEv.llvm.C4B43FD1
U
__PRETTY_FUNCTION__._ZNK4llvm14MachineOperand6getRegEv.llvm.B5105C7D
U
__PRETTY_FUNCTION__._ZNK4llvm18TargetRegisterInfo11getRegClassEj.llvm.FE201328
@@ -39,10 +40,12 @@
U .str.107.llvm.EEBE0BEA
U .str.108.llvm.EEBE0BEA
U .str.110.llvm.1C4EFC58
+ U .str.111.llvm.1C4EFC58
U .str.112.llvm.1C4EFC58
U .str.11.llvm.3D3A370D
U .str.127.llvm.EEBE0BEA
U .str.134.llvm.1C4EFC58
+ U .str.146.llvm.1C4EFC58
U .str.14.llvm.C4B43FD1
U .str.152.llvm.EEBE0BEA
U .str.15.llvm.C4B43FD1
Peter
On Thu, Mar 2, 2017 at 6:39 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> Do you know why it failed? That seems scary if enabling the cache triggers
> this.
>
> —
> Mehdi
>
> > On Mar 2, 2017, at 6:00 PM, Peter Collingbourne via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> >
> > Author: pcc
> > Date: Thu Mar 2 20:00:22 2017
> > New Revision: 296850
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=296850&view=rev
> > Log:
> > Revert r296730, "cmake: Configure the ThinLTO cache directory when using
> ELF lld or gold."
> >
> > Causes a build failure on the clang-with-thin-lto-ubuntu bot.
> > http://lab.llvm.org:8011/builders/clang-with-thin-lto-
> ubuntu/builds/2117/steps/build-stage3-compiler/logs/stdio
> >
> > Modified:
> > llvm/trunk/cmake/modules/HandleLLVMOptions.cmake
> >
> > Modified: llvm/trunk/cmake/modules/HandleLLVMOptions.cmake
> > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/cmake/
> modules/HandleLLVMOptions.cmake?rev=296850&r1=296849&r2=296850&view=diff
> > ============================================================
> ==================
> > --- llvm/trunk/cmake/modules/HandleLLVMOptions.cmake (original)
> > +++ llvm/trunk/cmake/modules/HandleLLVMOptions.cmake Thu Mar 2
> 20:00:22 2017
> > @@ -715,20 +715,11 @@ if(uppercase_LLVM_ENABLE_LTO STREQUAL "T
> > if(NOT LINKER_IS_LLD_LINK)
> > append("-flto=thin" CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
> > endif()
> > - # If the linker supports it, enable the lto cache. This improves
> initial build
> > - # time a little since we re-link a lot of the same objects, and
> significantly
> > - # improves incremental build time.
> > - # FIXME: We should move all this logic into the clang driver.
> > - if(APPLE)
> > - append("-Wl,-cache_path_lto,${PROJECT_BINARY_DIR}/lto.cache"
> > - CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
> > - elseif(UNIX AND LLVM_USE_LINKER STREQUAL "lld")
> > - append("-Wl,--thinlto-cache-dir=${PROJECT_BINARY_DIR}/lto.cache"
> > - CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
> > - elseif(LLVM_USE_LINKER STREQUAL "gold")
> > - append("-Wl,--plugin-opt,cache-dir=${PROJECT_BINARY_DIR}/lto.cache"
> > - CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
> > - endif()
> > + # On darwin, enable the lto cache. This improves initial build time a
> little
> > + # since we re-link a lot of the same objects, and significantly
> improves
> > + # incremental build time.
> > + append_if(APPLE "-Wl,-cache_path_lto,${PROJECT_BINARY_DIR}/lto.cache"
> > + CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
> > elseif(uppercase_LLVM_ENABLE_LTO STREQUAL "FULL")
> > append("-flto=full" CMAKE_CXX_FLAGS CMAKE_C_FLAGS)
> > if(NOT LINKER_IS_LLD_LINK)
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
--
--
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170302/332ba49f/attachment.html>
More information about the llvm-commits
mailing list