<div dir="ltr">I was able to get a relatively simple reproduction of the issue and posted it along with a fix: <a href="http://reviews.llvm.org/D18683">http://reviews.llvm.org/D18683</a><div><br></div><div>Unfortunately I had to resort to writing a unit test rather than using the normal test infrastructure since llvm-link links modules in a way that avoids the bug.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 3:10 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Mar 24, 2016 at 10:36 AM, Tim Armstrong via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>Thanks for the quick response Rafael, that's what I hoped to hear - I'll see what I can do!<br><br></div>The original repro is ~150000 lines of IR so I'll see if I can reduce it :)</div></div></blockquote><div><br></div></span><div>bugpoint may be helpful: <a href="http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html" target="_blank">http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html</a></div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><span><font color="#888888"><br><br></font></span></div><span><font color="#888888">- Tim<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 10:08 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 24 March 2016 at 12:18, Tim Armstrong via llvm-dev<br>
<div><div><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Hi All,<br>
><br>
>   I ran into what I think is a linker bug around structural uniquing of<br>
> types when trying to make a long-overdue upgrade from LLVM 3.3 to LLVM<br>
> 3.8.0. Verification can fail after linking together two well-formed modules<br>
> due to mismatched pointer types.<br>
><br>
> What happens is that both of the types in the source module get mapped to<br>
> the same type in the destination module. The old behaviour was to map each<br>
> type to the type in the destination with matching name and structure. This<br>
> means that the type signatures of functions called from the Dst module can<br>
> change, causing verification failures, e.g. if a call instruction originally<br>
> from Dst calls a function in Src with the wrong typed pointer.<br>
><br>
> Dst Module<br>
> ========<br>
> %"struct.impala_udf::TinyIntVal" = type { %"struct.impala_udf::AnyVal", i8 }<br>
> %"struct.impala_udf::AnyVal" = type { i8 }<br>
> %"struct.impala_udf::BooleanVal" = type { %"struct.impala_udf::AnyVal", i8 }<br>
><br>
> <forward declarations of IdentityTiny and IdentityBool><br>
><br>
> <functions that call IdentityTiny and IdentityBool><br>
><br>
> Src Module<br>
> ========<br>
> %"struct.impala_udf::BooleanVal" = type { %"struct.impala_udf::AnyVal", i8 }<br>
> %"struct.impala_udf::AnyVal" = type { i8 }<br>
> %"struct.impala_udf::TinyIntVal" = type { %"struct.impala_udf::AnyVal", i8 }<br>
><br>
> define i16 @IdentityTiny(%"struct.impala_udf::TinyIntVal"* nocapture<br>
> readonly dereferenceable(2) %arg) #0 {<br>
>   %1 = bitcast %"struct.impala_udf::TinyIntVal"* %arg to i16*<br>
>   %2 = load i16, i16* %1, align 1<br>
>   ret i16 %2<br>
> }<br>
><br>
> define i16 @IdentityBool(%"struct.impala_udf::BooleanVal"* nocapture<br>
> readonly dereferenceable(2) %arg) #0 {<br>
>   %1 = bitcast %"struct.impala_udf::BooleanVal"* %arg to i16*<br>
>   %2 = load i16, i16* %1, align 1<br>
>   ret i16 %2<br>
> }<br>
><br>
> Combined Module<br>
> ==============<br>
> %"struct.impala_udf::TinyIntVal" = type { %"struct.impala_udf::AnyVal", i8 }<br>
> %"struct.impala_udf::AnyVal" = type { i8 }<br>
> %"struct.impala_udf::BooleanVal" = type { %"struct.impala_udf::AnyVal", i8 }<br>
><br>
> <functions that call IdentityTiny and IdentityBool with TinyIntVal* and<br>
> BooleanVal* args><br>
><br>
> define i16 @IdentityTiny(%"struct.impala_udf::TinyIntVal"* nocapture<br>
> readonly dereferenceable(2) %arg) #0 {<br>
>   %1 = bitcast %"struct.impala_udf::TinyIntVal"* %arg to i16*<br>
>   %2 = load i16, i16* %1, align 1<br>
>   ret i16 %2<br>
> }<br>
><br>
> ; Function signature changed =><br>
> define i16 @IdentityBool(%"struct.impala_udf::TinyIntVal"* nocapture<br>
> readonly dereferenceable(2) %arg) #0 {<br>
>   %1 = bitcast %"struct.impala_udf::TinyIntVal"* %arg to i16*<br>
>   %2 = load i16, i16* %1, align 1<br>
>   ret i16 %2<br>
> }<br>
><br>
> This seems like a bug to me, I wouldn't expect this scenario to result in<br>
> malformed modules but it's not really clear what the expected behaviour of<br>
> the linker is in situations like this.<br>
><br>
> It seems like this hasn't been hit by the LLVM linker since it starts with<br>
> an empty module and links in all non-empty modules, so all non-opaque struct<br>
> types in the destination module are already structurally unique. In our case<br>
> we are starting with a main module then adding in IRBuilder code and code<br>
> from other modules.<br>
><br>
> I have a fix and I'm happy to put together a patch with regression tests,<br>
> but I wanted to check that this would be considered useful, given that it<br>
> doesn't seem to be a common use-case for LLVM and the planned work on<br>
> typeless pointers will make it irrelevant.<br>
<br>
</div></div>I would be interested in seeing the fix and full testcase.<br>
<br>
It has been a long time since I looked at the type merging, but I<br>
would expect it to work for this case.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>