Displaying 3 results from an estimated 3 matches for "arbitrary_suffix1".
Did you mean:
arbitrary_suffix2
2016 Apr 20
2
LTO and intrinsics mangling
...(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 stru...
2016 Apr 19
3
LTO and intrinsics mangling
...l change on a
> re-architecting effort here.
I sorry I missed this when it first went in. In general the name of
llvm types should not be significant. What was the motivation for
having it in the name of the intrinsic? Could we change to using
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.bar*> @llvm.masked.load.arbitrary_suffix2(<4 x
%struct.bar*>*, i32, <4 x i1>, <4 x %struct.bar*>)
Cheers,
Rafael
2016 Apr 18
7
LTO and intrinsics mangling
In the current mangling scheme for overloaded intrinsics we include overloaded type names in the intrinsic name. For example:
%struct.foobar = type { i32 }
declare <4 x %struct.foobar*> @llvm.masked.load.v4p0struct.foobar(<4 x %struct.foobar*>*, i32, <4 x i1>, <4 x %struct.foobar*>)
Verifier checks that an overloaded intrinsic name matches with its signature.
When