[llvm-dev] LTO and intrinsics mangling

Artur Pilipenko via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 20 12:28:40 PDT 2016


> On 20 Apr 2016, at 22:06, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>> The name of the struct is used in forming the arbitrary (unique) suffix.
>> It's essentially a hash(types) with a hash function intended to be somewhat
>> human readable.  :)
> 
> But if it is really an arbitrary suffix, why does it have to be
> updated in any fancy way? That is, given a module with
> 
> declare <4 x %struct.foo*> @llvm.masked.load.arbitrary_suffix1(<4 x
> %struct.foo*>*, i32, <4 x i1>, <4 x %struct.foo*>)
> 
> and another with
> 
> declare <4 x %struct.bar*> @llvm.masked.load.arbitrary_suffix2(<4 x
> %struct.bar*>*, i32, <4 x i1>, <4 x %struct.bar*>)
> 
> and given that the linker managed to merge struct.foo and struct.bar,
> couldn't we just keep
> 
> declare <4 x %struct.foo*> @llvm.masked.load.arbitrary_suffix1(<4 x
> %struct.foo*>*, i32, <4 x i1>, <4 x %struct.foo*>)
> 
> declare <4 x %struct.foo*> @llvm.masked.load.arbitrary_suffix2(<4 x
> %struct.foo*>*, i32, <4 x i1>, <4 x %struct.foo*>)
> 
> in the merged module? That is, we would have two declarations that
> will be codegened the same.
The invariant between the name and the signature is generic for all overloaded intrinsics and verified by generic code. Relaxing the invariant for masked load/store only seems ugly.

On the other hand, given the fact that we are moving towards opaque pointer type, I like the idea to use i8* pointers in masked load/store intrinsics proposed by Ahmed. So the generic mangling scheme is untouched and the problem with type renaming is avoided because we’ll only have primitive types as a part of intrinsic name.

Artur    
> 
> Cheers,
> Rafael



More information about the llvm-dev mailing list