[PATCH] D26212: IRMover: Avoid accidentally mapping types from the destination module (PR30799)

Mehdi AMINI via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 1 14:58:53 PDT 2016


mehdi_amini added inline comments.


================
Comment at: test/LTO/X86/type-mapping-bug.ll:3
+; RUN: llvm-as -o %t.src.bc %S/Inputs/type-mapping-src.ll
+; RUN: llvm-lto %t.dst.bc %t.src.bc -o=/dev/null
+
----------------
hans wrote:
> mehdi_amini wrote:
> > hans wrote:
> > > pcc wrote:
> > > > Would it be possible to write this test with `llvm-link` instead of `llvm-lto`?
> > > Sadly, I wasn't able to reproduce this with llvm-link, only with llvm-lto.
> > > 
> > > Some code path must be different. While I think it should be possible to trigger the same problem there, I couldn't figure out how to do it.
> > Likely not. I fixed a similar issues in r280599 / D23841 and it requires the LLVMContext to be initialized with ODR type uniquing, which only happens in LTO. (We may be able to add an option to llvm-link, but we can't really test it as it is supposed to be "NFC").
> Thanks for the pointer! Yes, that must be it.
> I'm kind of happy to see someone else has run into this. I thought I was about to go mad debugging it :-)
ODR type uniquing was introduced in the 3.9 release, so it can still be a bit rough around the edges...
(I'm debugging an infinite recursion in metadata in the IRMover when linking Webkit with ThinLTO these days)


https://reviews.llvm.org/D26212





More information about the llvm-commits mailing list