<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 18 Apr 2016, at 19:52, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" class="">mehdi.amini@apple.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Apr 18, 2016, at 9:45 AM, Artur Pilipenko via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<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>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I assume the verify does this just for internal consistency, if there is another good reason all of what I write below does not make sense probably...</div>
<div class=""><br class="">
</div>
<div class="">We could make it tolerating this by trying to remove the suffix for the types and accept that the intrinsic name matches the type name without the suffix?</div>
</div>
</div>
</div>
</blockquote>
There is no guarantee that two types which names differ by the suffix are the same. Even in LTO case we might have unrelated types with the same name in different modules (it’s basically my second example). I’m reluctant to relax the verification rules because
it only wraps the underlying issue and potentially allows incorrect code (the case when two unrelated types had the same name) to pass verification. <br class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">
<div class=""><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<div class="" style="word-wrap:break-word">
<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 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 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>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">In the same way, I'd try to avoid "autoupgrading" in this case? I'm puzzled by the fact that round-tripping to bitcode within the same version of LLVM triggers an "upgrade”.</div>
</div>
</div>
</div>
</blockquote>
In my view auto-upgrade is triggered on a malformed module (it wouldn’t pass verification). That’s actually one of the reasons to verify that the name matches with the signature - AutoUpgrade relies on that fact.</div>
<div><br class="">
</div>
<div>Artur<br class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">-- </div>
<div class="">Mehdi</div>
<div class=""><br class="">
</div>
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<div class="" style="word-wrap:break-word">
<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 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 class=""></div>
</div>
<div style="word-wrap:break-word" class="">
<div class=""></div>
</div>
<div class="" style="word-wrap:break-word">
<div class=""></div>
</div>
</div>
<span id="cid:40C0890F71165A47BA2488C363792EDA@exch021.domain.local" class=""><bar.c></span><span id="cid:8715BA10C0108E46A14528FAD6972E50@exch021.domain.local" class=""><foo.c></span>_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>