<div dir="ltr"><div><div><div>Hi All,<br><br>  I ran into what I think is a linker bug around structural uniquing of types when trying to make a long-overdue upgrade from LLVM 3.3 to LLVM 3.8.0. Verification can fail after linking together two well-formed modules due to mismatched pointer types.<br><br>What happens is that both of the types in the source
 module get mapped to the same type in the destination module. The old 
behaviour was to map each type to the type in the destination with 
matching name and structure.  This means that the type signatures of functions called from the Dst module can change, causing verification failures, e.g. if a
 call instruction originally from Dst calls a function in Src with the 
wrong typed pointer.<br><br></div><div>Dst Module<br>========<br></div><div>%"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></div><div><forward declarations of IdentityTiny and IdentityBool><br></div><div><br></div><div><functions that call IdentityTiny and IdentityBool><br><br><div>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 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 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></div><div>Combined Module<br>==============<br><div>%"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></div><div><functions that call IdentityTiny and IdentityBool with TinyIntVal* and BooleanVal* args><br><div><br>define i16 @IdentityTiny(%"struct.impala_udf::TinyIntVal"* nocapture 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 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>}</div></div></div></div><div><br></div><div>This seems like a bug to me, I wouldn't expect this scenario to result in malformed modules but it's not really clear what the expected behaviour of the linker is in situations like this.<br></div><div><br></div>It seems like this hasn't been hit by the LLVM linker since it starts with an empty module and links in all non-empty modules, so all non-opaque struct types in the destination module are already structurally unique. In our case we are starting with a main module then adding in IRBuilder code and code from other modules.<br><br></div>I have a fix and I'm happy to put together a patch with regression tests, but I wanted to check that this would be considered useful, given that it doesn't seem to be a common use-case for LLVM and the planned work on typeless pointers will make it irrelevant. <br><br></div>- Tim<br></div>