[PATCH] D18683: Fix bug with duplicate struct types in Linker

[Tim Armstrong via llvm-commits]

The difficulty is that the IR verifier and various assertions in the
codebase care about identity-equality, not just structural equality and
it's not always obvious which usage patterns are going to lead to
verification failures, aside from the traditional compilation model of
building separate modules and linking them together at the end.

I may look at doing that instead since it seems like that is must better
supported/tested, but I'd be concerned about the additional overhead of
extra linking steps.

I can add bitcasts by trial and error, but it seems like to be confident
that I'm not going to produce invalid code I'd essentially need to bitcast
all function arguments anytime I call a function that has been sent through
the linker. Is that it, more or less?

On 2 May 2016 at 05:42, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

> > I get that it's an open-source project and use-cases only get supported
> if someone contributes time, so I'm trying to help here. The change makes
> the code simpler, internally consistent and fixes a use case that
> previously worked.
> >
> > Are you just saying that IRMover is only meant to work for the
> particular use-case of the LLVM linker and other people who are trying to
> use it as a utiltiy to move IR between modules just need to deal with it?
>
> Not necessarily, but the invariant you are trying to support is not
> the direction we are trying to move. In fact, it is the opposite. You
> are trying to say that if there is a type with a given name in the
> destination it will be safe to assume it will be use when linking in
> code.
>
> The direction we are trying to move to is that types are non recursive
> and always structurally merged.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160504/e642f17a/attachment.html>