llvm dev - Jul 2016 - [ThinLTO] Using two different IRMovers for the same composite module? (related to PR28180)

On Fri, Jul 22, 2016 at 2:44 PM, Davide Italiano <davide at freebsd.org>
wrote:
> On Fri, Jul 22, 2016 at 2:34 PM, Taewook Oh via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Yes, I have the repro, though I can’t publish it externally. It would
be
>> great if you can upstream the patch so I can try it. Thank you for your
>> explanation as well!
>
> There's a reproducer attached (obtained via lld --reproduce option).
> If that doesn't work, you can checkout mozjs and try to reduce from
> there.
> It happens while doing an LTO build with lld.
> I have a fix for that (Mehdi has one as well, apparently) in my local
> tree, but I don't have time to reduce. If you can take care of that,
> chances are that an upstream fix will be committed shortly after.
>
Just to clarify, I'm talking about the issue in PR28180. I can't
comment about the ThinLTO one, sorry.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare

> On Jul 22, 2016, at 2:47 PM, Davide Italiano <davide at freebsd.org>
wrote:
> 
> On Fri, Jul 22, 2016 at 2:44 PM, Davide Italiano <davide at
freebsd.org> wrote:
>> On Fri, Jul 22, 2016 at 2:34 PM, Taewook Oh via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> Yes, I have the repro, though I can’t publish it externally. It
would be
>>> great if you can upstream the patch so I can try it. Thank you for
your
>>> explanation as well!
>> 
>> There's a reproducer attached (obtained via lld --reproduce
option).
>> If that doesn't work, you can checkout mozjs and try to reduce from
>> there.
>> It happens while doing an LTO build with lld.
>> I have a fix for that (Mehdi has one as well, apparently) in my local
>> tree, but I don't have time to reduce. If you can take care of
that,
>> chances are that an upstream fix will be committed shortly after.
>> 
> 
> Just to clarify, I'm talking about the issue in PR28180. I can't
> comment about the ThinLTO one, sorry.
If lld is setting enableDebugTypeODRUniquing(); on the context and isn’t using
the IRMover to target an empty module, it can be the same bug.
I mentioned that it should touch only ThinLTO but I had ld64 in mind.

— 
Mehdi

It seems that the patch works for me as well, though the linker crashes with
another error after that. Thanks!

Mehdi, I couldn’t quite understand what do you mean by you don’t have a repro so
you couldn’t upstream the patch. Aren’t .ll files you attached sufficient to
submit along with the patch? If there is anything I can help you to upstream it,
please let me know.

-- Taewook

On 7/22/16, 2:52 PM, "mehdi.amini at apple.com on behalf of Mehdi
Amini" <mehdi.amini at apple.com> wrote:

> On Jul 22, 2016, at 2:47 PM, Davide Italiano <davide at freebsd.org>
wrote:
> 
> On Fri, Jul 22, 2016 at 2:44 PM, Davide Italiano <davide at
freebsd.org> wrote:
>> On Fri, Jul 22, 2016 at 2:34 PM, Taewook Oh via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> Yes, I have the repro, though I can’t publish it externally. It
would be
>>> great if you can upstream the patch so I can try it. Thank you for
your
>>> explanation as well!
>> 
>> There's a reproducer attached (obtained via lld --reproduce
option).
>> If that doesn't work, you can checkout mozjs and try to reduce from
>> there.
>> It happens while doing an LTO build with lld.
>> I have a fix for that (Mehdi has one as well, apparently) in my local
>> tree, but I don't have time to reduce. If you can take care of
that,
>> chances are that an upstream fix will be committed shortly after.
>> 
> 
> Just to clarify, I'm talking about the issue in PR28180. I can't
> comment about the ThinLTO one, sorry.
If lld is setting enableDebugTypeODRUniquing(); on the context and isn’t using
the IRMover to target an empty module, it can be the same bug.
I mentioned that it should touch only ThinLTO but I had ld64 in mind.

— 
Mehdi