[PATCH] D43199: [IRMover] Implement name based structure type mapping

[Evgeny Leviant via llvm-commits]

> This suggests that ThinLTO should be changed. It is fine to start with a
> non empty module, but it should scan its types so that Foo is found to
> be isomorphic to Bar an not imported.

I don't see how this can be done as you can have both Foo and Bar imported from different modules and still get mapping failure.
The problem is that addNonOpaque registers a single entry for all isomorphic structure types. Can you please elaborate your idea?
________________________________________
От: Rafael Avila de Espindola <rafael.espindola at gmail.com>
Отправлено: 14 февраля 2018 г. 18:48
Кому: Evgeny Leviant; reviews+D43199+public+9fc6d07c4d39554e at reviews.llvm.org; Eugene Leviant via Phabricator; joker.eph at gmail.com; tejohnson at google.com
Копия: George Rimar; llvm-commits at lists.llvm.org
Тема: Re: [PATCH] D43199: [IRMover] Implement name based structure type mapping

Evgeny Leviant <eleviant at accesssoftek.com> writes:

>> Why do you need ThinLTO to test a type merging feature? Could this use
>> llvm-link?
>
> The specifics of thinlto import is that module is partially  imported to an existing module, while llvm-link imports all source modules to an empty destination module.
> This causes differences in how structure types are processed: thinlto calls addNonOpaque for all structure types in non-empty destination module before
> actual import is started (see IRMover constructor) and llvm-link calls addNonOpaque(S) during import process when structure S is being imported to the destination
> module.
>
> As a result structure Foo will not be imported at all if you use llvm-link, because it is isomorphic to previously declared Bar and all references to Foo
> will be replaced by references to Bar in the destination module. This is cool, but I don't think it is usable for thinlto as we're doing partial link.

This suggests that ThinLTO should be changed. It is fine to start with a
non empty module, but it should scan its types so that Foo is found to
be isomorphic to Bar an not imported.

I would also suggest adding a flag to llvm-link to create the Linker
with a given bitcode file. That should allow us to test this with
llvm-link.

Cheers,
Rafael