[llvm-dev] LTO and intrinsics mangling

Rafael Espíndola via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 20 12:29:58 PDT 2016


On 20 April 2016 at 15:28, Artur Pilipenko <apilipenko at azulsystems.com> wrote:
>
>> 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.

Sounds good to me too.

Cheers,
Rafael


More information about the llvm-dev mailing list