[llvm-commits] [llvm] r91626 - in /llvm/trunk: lib/ExecutionEngine/JIT/JIT.cpp lib/ExecutionEngine/JIT/JIT.h lib/ExecutionEngine/JIT/JITEmitter.cpp unittests/ExecutionEngine/JIT/JITTest.cpp

[nicolas geoffray]

Hi Jeffrey,


> > This should be guarded by a lazy compilation enabled check.
>
> What's the actual failure you see? As far as I understand, it's lazy
> bitcode loading that causes functions to have ghost linkage, not lazy
> compilation.
>

Yes, sorry, that was lazy bitcode loading. This should not be triggered
here.

>
> Until http://llvm.org/bugs/show_bug.cgi?id=5737 is fixed, there's no
> way to tell whether a ghost function is available_externally without
> materializing it, so I'd expect not having this to break all users of
> lazy bitcode loading, not just users who also compile lazily.
>
>
Ah, that's unfortunate. Two things incompatible with each other....  Still,
the behavior was OK before your change, so I guess both ways do not fix
PR5737. I'd really like to see the old behavior coming back again until a
proper fix to PR5737 is submitted.

Declaration() || F->hasAvailableExternallyLinkage()) {
> >
> > Why remove the hasNotBeenReadFromBitcode? The hasNotBeenReadFromBitcode
> > function verifies that the linkage of the function is GhostLinkage, which
> is
> > used by lazy compilation. So users that use lazy compilation require the
> > call to hasNotBeenReadFromBitcode.
>
> Given the above call to materializeFunction(F),
> hasNotBeenReadFromBitcode should always be false, so testing it is
> redundant. I could add an assert() if you want.
>
>
No, the matierialize function should not be there in the first place.

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20091221/9e7590f8/attachment.html>