<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 04/18/2016 09:45 AM, Artur Pilipenko
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:5D33D54D-CABD-431E-B219-29F61DD699E6@azulsystems.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="" style="word-wrap:break-word">
<div class="">In the current mangling scheme for overloaded
intrinsics we include overloaded type names in the intrinsic
name. For example:</div>
<div class=""><br class="">
</div>
<div class="">%struct.foobar = type { i32 }</div>
<div class="">declare <4 x %struct.foobar*>
@llvm.masked.load.v4p0struct.foobar(<4 x
%struct.foobar*>*, i32, <4 x i1>, <4 x
%struct.foobar*>)</div>
<div class=""><br class="">
</div>
<div class="">Verifier checks that an overloaded intrinsic name
matches with its signature.</div>
<div class=""><br class="">
</div>
<div class="">When different modules are loaded in LTO
configuration with the same LLVMContext, types with the same
name from different modules are renamed so their names are
unique (%struct.foobar in the second module becomes
%struct.foobar.0). After renaming intrinsic names and
signatures can become inconsistent.</div>
</div>
</blockquote>
This seems like a clear bug in the module loading. If we're
changing type names, we need to change the intrinsic signatures as
well. <br>
<blockquote
cite="mid:5D33D54D-CABD-431E-B219-29F61DD699E6@azulsystems.com"
type="cite">
<div class="" style="word-wrap:break-word">
<div class=""><br class="">
</div>
<div class="">Usually it slips unnoticed because we don't verify
individual modules and eventually map isomorphic types to a
single type. So isomorphic types get their original names.
Although in some cases it causes problems. </div>
<div class=""><br class="">
</div>
<div class="">Initially I came across the problem with my recent
change which added an overloaded type to the masked load/store
intrinsics (<a moz-do-not-send="true"
href="http://reviews.llvm.org/D17270" class="">http://reviews.llvm.org/D17270</a>).
The discrepancy between the name and the signature triggers
auto-upgrade bit from my patch converting an incorrect
mangling to the correct one. But later after remapping of
isomorphic types when we return to the original type name this
“updated" intrinsic name become invalid.</div>
<div class=""><br class="">
</div>
<div class="">Another way to trigger the problem is to have
different types with the same name in different modules.
Corresponding test case is attached. In this case types in
different modules will be renamed but the intrinsics from
different modules will have the same name which will be caught
by verifier.</div>
<div class=""><br class="">
</div>
<div class="">As a possible solution we can use AutoUpgrade to
handle the situation when the name of the intrinsic doesn't
match with its signature. In such cases we have to rename the
intrinsic. Then during linking if we map some isomorphic types
we have to update intrinsics names. To do that we have to
teach IRMover to update intrinsics signatures according to the
types mapping.</div>
<div class=""><br class="">
</div>
<div class="">Does this sound reasonable? Are there any other
alternatives?</div>
</div>
</blockquote>
Given our current intrinsic naming scheme, the approach you've
described seems entirely reasonable. <br>
<br>
An alternate scheme would be to make the intrinsic signatures
insensitive to the struct naming. (That was probably a bad idea on
my part to start with, sorry!) I would argue that we should not
block your original change on a re-architecting effort here. <br>
<blockquote
cite="mid:5D33D54D-CABD-431E-B219-29F61DD699E6@azulsystems.com"
type="cite">
<div class="" style="word-wrap:break-word">
<div class=""><br class="">
</div>
<div class="">Artur</div>
<div class=""><br class="">
</div>
<div class="">To reproduce:</div>
<div class="">
<div class="">$ clang -O3 -S -march=core-avx2 -emit-llvm bar.c</div>
<div class="">$ clang -O3 -S -march=core-avx2 -emit-llvm foo.c</div>
<div class="">$ llvm-as bar.ll</div>
<div class="">$ llvm-as foo.ll</div>
<div class="">$ llvm-lto foo.bc bar.bc</div>
<div class="">
<div class="">Invalid user of intrinsic instruction!</div>
<div class=""><4 x %struct.foobar.0*> (<4 x
%struct.foobar.0*>*, i32, <4 x i1>, <4 x
%struct.foobar.0*>)* bitcast (<4 x
%struct.foobar*> (<4 x %struct.foobar*>*, i32,
<4 x i1>, <4 x %struct.foobar*>)*
@llvm.masked.load.v4p0struct.foobar to <4 x
%struct.foobar.0*> (<4 x %struct.foobar.0*>*,
i32, <4 x i1>, <4 x %struct.foobar.0*>)*)</div>
<div class="">Invalid user of intrinsic instruction!</div>
<div class="">void (<4 x %struct.foobar.0*>, <4 x
%struct.foobar.0*>*, i32, <4 x i1>)* bitcast
(void (<4 x %struct.foobar*>, <4 x
%struct.foobar*>*, i32, <4 x i1>)*
@llvm.masked.store.v4p0struct.foobar to void (<4 x
%struct.foobar.0*>, <4 x %struct.foobar.0*>*,
i32, <4 x i1>)*)</div>
<div class="">LLVM ERROR: Broken module found, compilation
aborted!</div>
</div>
</div>
</div>
<div style="word-wrap:break-word">
</div>
<div class="" style="word-wrap:break-word">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>