llvm dev - Apr 2016 - LTO and intrinsics mangling

> 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.

Cheers,
Rafael

> 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

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