<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 10:52 AM, Ahmed Bougacha
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAOprbYT6JfaXwZUvQusb7iVG2MEFvKMNTGuEPwgGpVskOFgFHA@mail.gmail.com"
type="cite">
<div dir="ltr">On Mon, Apr 18, 2016 at 9:45 AM, Artur Pilipenko
via llvm-dev <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<br>
> In the current mangling scheme for overloaded intrinsics we
include<br>
> overloaded type names in the intrinsic name. For example:<br>
><br>
> %struct.foobar = type { i32 }<br>
> declare <4 x %struct.foobar*>
@llvm.masked.load.v4p0struct.foobar(<4 x<br>
> %struct.foobar*>*, i32, <4 x i1>, <4 x
%struct.foobar*>)<br>
><br>
> Verifier checks that an overloaded intrinsic name matches
with its<br>
> signature.<br>
><br>
> When different modules are loaded in LTO configuration with
the same<br>
> LLVMContext, types with the same name from different
modules are renamed so<br>
> their names are unique (%struct.foobar in the second module
becomes<br>
> %struct.foobar.0). After renaming intrinsic names and
signatures can become<br>
> inconsistent.<br>
><br>
> Usually it slips unnoticed because we don't verify
individual modules and<br>
> eventually map isomorphic types to a single type. So
isomorphic types get<br>
> their original names. Although in some cases it causes
problems.<br>
><br>
> Initially I came across the problem with my recent change
which added an<br>
> overloaded type to the masked load/store intrinsics<br>
> (<a moz-do-not-send="true"
href="http://reviews.llvm.org/D17270" target="_blank">http://reviews.llvm.org/D17270</a>).
The discrepancy between the name and the<br>
> signature triggers auto-upgrade bit from my patch
converting an incorrect<br>
> mangling to the correct one. But later after remapping of
isomorphic types<br>
> when we return to the original type name this “updated"
intrinsic name<br>
> become invalid.<br>
><br>
> Another way to trigger the problem is to have different
types with the same<br>
> name in different modules. Corresponding test case is
attached. In this case<br>
> types in different modules will be renamed but the
intrinsics from different<br>
> modules will have the same name which will be caught by
verifier.<br>
><br>
> As a possible solution we can use AutoUpgrade to handle the
situation when<br>
> the name of the intrinsic doesn't match with its signature.
In such cases we<br>
> have to rename the intrinsic. Then during linking if we map
some isomorphic<br>
> types we have to update intrinsics names. To do that we
have to teach<br>
> IRMover to update intrinsics signatures according to the
types mapping.<br>
><br>
> Does this sound reasonable? Are there any other
alternatives?<br>
<br>
Would demoting pointer types to pNi8 work?<br>
<br>
As you say, that could potentially mask problems, but I don't
think the type of the masked load/store matters, only the types
of the pointer elements at the subsequent loads/stores.<br>
In other words, this sounds equivalent to opaque pointer types
to me. A pointer load shouldn't care about the type.<br>
</div>
</blockquote>
I went down this path too. It doesn't work unfortunately. The
problem is that the value type of the store is also part of the
signature and could be a struct type. Analogously, the same problem
exists for the return type of the load. We can and do lower
loads/stores of different value types differently. Memory isn't
typed, but the operation is. <br>
<blockquote
cite="mid:CAOprbYT6JfaXwZUvQusb7iVG2MEFvKMNTGuEPwgGpVskOFgFHA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
-Ahmed<br>
<br>
> Artur<br>
><br>
> To reproduce:<br>
> $ clang -O3 -S -march=core-avx2 -emit-llvm bar.c<br>
> $ clang -O3 -S -march=core-avx2 -emit-llvm foo.c<br>
> $ llvm-as bar.ll<br>
> $ llvm-as foo.ll<br>
> $ llvm-lto foo.bc bar.bc<br>
> Invalid user of intrinsic instruction!<br>
> <4 x %struct.foobar.0*> (<4 x
%struct.foobar.0*>*, i32, <4 x i1>, <4 x<br>
> %struct.foobar.0*>)* bitcast (<4 x
%struct.foobar*> (<4 x %struct.foobar*>*,<br>
> i32, <4 x i1>, <4 x %struct.foobar*>)*
@llvm.masked.load.v4p0struct.foobar<br>
> to <4 x %struct.foobar.0*> (<4 x
%struct.foobar.0*>*, i32, <4 x i1>, <4 x<br>
> %struct.foobar.0*>)*)<br>
> Invalid user of intrinsic instruction!<br>
> void (<4 x %struct.foobar.0*>, <4 x
%struct.foobar.0*>*, i32, <4 x i1>)*<br>
> bitcast (void (<4 x %struct.foobar*>, <4 x
%struct.foobar*>*, i32, <4 x<br>
> i1>)* @llvm.masked.store.v4p0struct.foobar to void
(<4 x %struct.foobar.0*>,<br>
> <4 x %struct.foobar.0*>*, i32, <4 x i1>)*)<br>
> LLVM ERROR: Broken module found, compilation aborted!<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
</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>