<div dir="ltr">On Mon, Apr 18, 2016 at 9:45 AM, Artur Pilipenko via llvm-dev <<a 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 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><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 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" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>><br></div>