LTO and intrinsics mangling

Project Infrastructure LLVM Dev List Archives
#1

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 different modules are loaded in LTO configuration with the same LLVMContext, types with the same name from different modules are renamed so their names are unique (%struct.foobar in the second module becomes %struct.foobar.0). After renaming intrinsic names and signatures can become inconsistent.

Usually it slips unnoticed because we don’t verify individual modules and eventually map isomorphic types to a single type. So isomorphic types get their original names. Although in some cases it causes problems.

Initially I came across the problem with my recent change which added an overloaded type to the masked load/store intrinsics (http://reviews.llvm.org/D17270). The discrepancy between the name and the signature triggers auto-upgrade bit from my patch converting an incorrect mangling to the correct one. But later after remapping of isomorphic types when we return to the original type name this “updated" intrinsic name become invalid.

Another way to trigger the problem is to have different types with the same name in different modules. Corresponding test case is attached. In this case types in different modules will be renamed but the intrinsics from different modules will have the same name which will be caught by verifier.

As a possible solution we can use AutoUpgrade to handle the situation when the name of the intrinsic doesn’t match with its signature. In such cases we have to rename the intrinsic. Then during linking if we map some isomorphic types we have to update intrinsics names. To do that we have to teach IRMover to update intrinsics signatures according to the types mapping.

Does this sound reasonable? Are there any other alternatives?

Artur

To reproduce:

$ clang -O3 -S -march=core-avx2 -emit-llvm bar.c
$ clang -O3 -S -march=core-avx2 -emit-llvm foo.c
$ llvm-as bar.ll
$ llvm-as foo.ll
$ llvm-lto foo.bc bar.bc

Invalid user of intrinsic instruction!
<4 x %struct.foobar.0*> (<4 x %struct.foobar.0*>, i32, <4 x i1>, <4 x %struct.foobar.0>)* bitcast (<4 x %struct.foobar*> (<4 x %struct.foobar*>, i32, <4 x i1>, <4 x %struct.foobar>)* @llvm.masked.load.v4p0struct.foobar to <4 x %struct.foobar.0*> (<4 x %struct.foobar.0*>, i32, <4 x i1>, <4 x %struct.foobar.0>))
Invalid user of intrinsic instruction!
void (<4 x %struct.foobar.0>, <4 x %struct.foobar.0*>, i32, <4 x i1>) bitcast (void (<4 x %struct.foobar*>, <4 x %struct.foobar*>, i32, <4 x i1>) @llvm.masked.store.v4p0struct.foobar to void (<4 x %struct.foobar.0*>, <4 x %struct.foobar.0*>, i32, <4 x i1>))
LLVM ERROR: Broken module found, compilation aborted!

bar.c (218 Bytes)

foo.c (206 Bytes)

#2

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.

I assume the verify does this just for internal consistency, if there is another good reason all of what I write below does not make sense probably…

We could make it tolerating this by trying to remove the suffix for the types and accept that the intrinsic name matches the type name without the suffix?

When different modules are loaded in LTO configuration with the same LLVMContext, types with the same name from different modules are renamed so their names are unique (%struct.foobar in the second module becomes %struct.foobar.0). After renaming intrinsic names and signatures can become inconsistent.

Usually it slips unnoticed because we don’t verify individual modules and eventually map isomorphic types to a single type. So isomorphic types get their original names. Although in some cases it causes problems.

Initially I came across the problem with my recent change which added an overloaded type to the masked load/store intrinsics (http://reviews.llvm.org/D17270). The discrepancy between the name and the signature triggers auto-upgrade bit from my patch converting an incorrect mangling to the correct one. But later after remapping of isomorphic types when we return to the original type name this “updated" intrinsic name become invalid.

In the same way, I’d try to avoid “autoupgrading” in this case? I’m puzzled by the fact that round-tripping to bitcode within the same version of LLVM triggers an “upgrade”.

#3

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.

I assume the verify does this just for internal consistency, if there is another good reason all of what I write below does not make sense probably…

We could make it tolerating this by trying to remove the suffix for the types and accept that the intrinsic name matches the type name without the suffix?

There is no guarantee that two types which names differ by the suffix are the same. Even in LTO case we might have unrelated types with the same name in different modules (it’s basically my second example). I’m reluctant to relax the verification rules because it only wraps the underlying issue and potentially allows incorrect code (the case when two unrelated types had the same name) to pass verification.

When different modules are loaded in LTO configuration with the same LLVMContext, types with the same name from different modules are renamed so their names are unique (%struct.foobar in the second module becomes %struct.foobar.0). After renaming intrinsic names and signatures can become inconsistent.

Usually it slips unnoticed because we don’t verify individual modules and eventually map isomorphic types to a single type. So isomorphic types get their original names. Although in some cases it causes problems.

Initially I came across the problem with my recent change which added an overloaded type to the masked load/store intrinsics (http://reviews.llvm.org/D17270). The discrepancy between the name and the signature triggers auto-upgrade bit from my patch converting an incorrect mangling to the correct one. But later after remapping of isomorphic types when we return to the original type name this “updated" intrinsic name become invalid.

In the same way, I’d try to avoid “autoupgrading” in this case? I’m puzzled by the fact that round-tripping to bitcode within the same version of LLVM triggers an "upgrade”.

In my view auto-upgrade is triggered on a malformed module (it wouldn’t pass verification). That’s actually one of the reasons to verify that the name matches with the signature - AutoUpgrade relies on that fact.

Artur

#4

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 different modules are loaded in LTO configuration with the same
LLVMContext, types with the same name from different modules are renamed so
their names are unique (%struct.foobar in the second module becomes
%struct.foobar.0). After renaming intrinsic names and signatures can become
inconsistent.

Usually it slips unnoticed because we don’t verify individual modules and
eventually map isomorphic types to a single type. So isomorphic types get
their original names. Although in some cases it causes problems.

Initially I came across the problem with my recent change which added an
overloaded type to the masked load/store intrinsics
(http://reviews.llvm.org/D17270). The discrepancy between the name and the
signature triggers auto-upgrade bit from my patch converting an incorrect
mangling to the correct one. But later after remapping of isomorphic types
when we return to the original type name this “updated" intrinsic name
become invalid.

Another way to trigger the problem is to have different types with the same
name in different modules. Corresponding test case is attached. In this case
types in different modules will be renamed but the intrinsics from different
modules will have the same name which will be caught by verifier.

As a possible solution we can use AutoUpgrade to handle the situation when
the name of the intrinsic doesn’t match with its signature. In such cases we
have to rename the intrinsic. Then during linking if we map some isomorphic
types we have to update intrinsics names. To do that we have to teach
IRMover to update intrinsics signatures according to the types mapping.

Does this sound reasonable? Are there any other alternatives?

Would demoting pointer types to pNi8 work?

As you say, that could potentially mask problems, but I don’t think the type of the masked load/store matters, only the types of the pointer elements at the subsequent loads/stores.
In other words, this sounds equivalent to opaque pointer types to me. A pointer load shouldn’t care about the type.

-Ahmed

#5

This seems like a clear bug in the module loading. If we’re changing type names, we need to change the intrinsic signatures as well. Given our current intrinsic naming scheme, the approach you’ve described seems entirely reasonable. An alternate scheme would be to make the intrinsic signatures insensitive to the struct naming. (That was probably a bad idea on my part to start with, sorry!) I would argue that we should not block your original change on a re-architecting effort here.

#6

Relaxing the verifier here definitely sounds like the wrong approach. Philip

#7

This does seem questionable. It’s doesn’t avoid the root issue - which is that we’re not renaming intrinsics when renaming types - but changing this would seem reasonable to me. It sounds like we might be relying on the upgrade functionality to paper over problems with type renaming. (And possibly other things…?) Philip

#8

I went down this path too. It doesn’t work unfortunately. The problem is that the value type of the store is also part of the signature and could be a struct type. Analogously, the same problem exists for the return type of the load. We can and do lower loads/stores of different value types differently. Memory isn’t typed, but the operation is.

#9

You're right, but I don't think that applies to masked load/stores, as
the value type can't be a struct type, it can only be a pointer to
struct type (langref says "The loaded data is a vector of any integer,
floating point or pointer data type.").

And since the backend only distinguishes pointer types based on
addresspace, pNi8 seems sufficient, no?

-Ahmed

#10

Does this sound reasonable? Are there any other alternatives?

Would demoting pointer types to pNi8 work?

As you say, that could potentially mask problems, but I don't think the type of the masked load/store matters, only the types of the pointer elements at the subsequent loads/stores.
In other words, this sounds equivalent to opaque pointer types to me. A pointer load shouldn't care about the type.

I went down this path too. It doesn't work unfortunately. The problem is that the value type of the store is also part of the signature and could be a struct type. Analogously, the same problem exists for the return type of the load. We can and do lower loads/stores of different value types differently. Memory isn't typed, but the operation is.

You're right, but I don't think that applies to masked load/stores, as
the value type can't be a struct type, it can only be a pointer to
struct type (langref says "The loaded data is a vector of any integer,
floating point or pointer data type.").

Er, not sure what you're getting at. The value type has to match the pointee type of the address type. If we can't have a value type which is a struct, how'd we end up with a struct typed pointer?

#11

Does this sound reasonable? Are there any other alternatives?

Would demoting pointer types to pNi8 work?

As you say, that could potentially mask problems, but I don't think the
type of the masked load/store matters, only the types of the pointer
elements at the subsequent loads/stores.
In other words, this sounds equivalent to opaque pointer types to me. A
pointer load shouldn't care about the type.

I went down this path too. It doesn't work unfortunately. The problem
is that the value type of the store is also part of the signature and could
be a struct type. Analogously, the same problem exists for the return type
of the load. We can and do lower loads/stores of different value types
differently. Memory isn't typed, but the operation is.

You're right, but I don't think that applies to masked load/stores, as
the value type can't be a struct type, it can only be a pointer to
struct type (langref says "The loaded data is a vector of any integer,
floating point or pointer data type.").

Er, not sure what you're getting at. The value type has to match the
pointee type of the address type. If we can't have a value type which is a
struct, how'd we end up with a struct typed pointer?

It's the pointee type that's a struct pointer. Artur's example is:

  %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*>)

Which - I think - is guaranteed to lower equivalently to:
  declare <4 x i8*> @llvm.masked.load.v4p0i8(<4 x i8*>*, i32, <4 x
i1>, <4 x i8*>)

I think you're imagining something like:
  declare <4 x %struct.foobar> @llvm.masked.load.p0v4struct.foobar(<4
x %struct.foobar>*, i32, <4 x i1>, <4 x %struct.foobar>)

But, according to the langref, that's forbidden.
Am I making sense?

-Ahmed

#12

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

#13

Does this sound reasonable? Are there any other alternatives?

Would demoting pointer types to pNi8 work?

As you say, that could potentially mask problems, but I don't think the
type of the masked load/store matters, only the types of the pointer
elements at the subsequent loads/stores.
In other words, this sounds equivalent to opaque pointer types to me. A
pointer load shouldn't care about the type.

I went down this path too. It doesn't work unfortunately. The problem
is that the value type of the store is also part of the signature and could
be a struct type. Analogously, the same problem exists for the return type
of the load. We can and do lower loads/stores of different value types
differently. Memory isn't typed, but the operation is.

You're right, but I don't think that applies to masked load/stores, as
the value type can't be a struct type, it can only be a pointer to
struct type (langref says "The loaded data is a vector of any integer,
floating point or pointer data type.").

Er, not sure what you're getting at. The value type has to match the
pointee type of the address type. If we can't have a value type which is a
struct, how'd we end up with a struct typed pointer?

It's the pointee type that's a struct pointer. Artur's example is:

   %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*>)

Which - I think - is guaranteed to lower equivalently to:
   declare <4 x i8*> @llvm.masked.load.v4p0i8(<4 x i8*>*, i32, <4 x
i1>, <4 x i8*>)

I think you're imagining something like:
   declare <4 x %struct.foobar> @llvm.masked.load.p0v4struct.foobar(<4
x %struct.foobar>*, i32, <4 x i1>, <4 x %struct.foobar>)

But, according to the langref, that's forbidden.
Am I making sense?

The example does convey your point, though you're wording is still confusing. :slight_smile: I get what you intend. You're basically suggesting we canonicalize the *vector of pointers* to be *vector of i8 pointers*. That would seem reasonable to me.

#14

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 different modules are loaded in LTO configuration with the same
LLVMContext, types with the same name from different modules are renamed so
their names are unique (%struct.foobar in the second module becomes
%struct.foobar.0). After renaming intrinsic names and signatures can become
inconsistent.

This seems like a clear bug in the module loading. If we're changing type
names, we need to change the intrinsic signatures as well.

Usually it slips unnoticed because we don't verify individual modules and
eventually map isomorphic types to a single type. So isomorphic types get
their original names. Although in some cases it causes problems.

Initially I came across the problem with my recent change which added an
overloaded type to the masked load/store intrinsics
(http://reviews.llvm.org/D17270). The discrepancy between the name and the
signature triggers auto-upgrade bit from my patch converting an incorrect
mangling to the correct one. But later after remapping of isomorphic types
when we return to the original type name this “updated" intrinsic name
become invalid.

Another way to trigger the problem is to have different types with the same
name in different modules. Corresponding test case is attached. In this case
types in different modules will be renamed but the intrinsics from different
modules will have the same name which will be caught by verifier.

As a possible solution we can use AutoUpgrade to handle the situation when
the name of the intrinsic doesn't match with its signature. In such cases we
have to rename the intrinsic. Then during linking if we map some isomorphic
types we have to update intrinsics names. To do that we have to teach
IRMover to update intrinsics signatures according to the types mapping.

Does this sound reasonable? Are there any other alternatives?

Given our current intrinsic naming scheme, the approach you've described
seems entirely reasonable.

An alternate scheme would be to make the intrinsic signatures insensitive to
the struct naming. (That was probably a bad idea on my part to start with,
sorry!) I would argue that we should not block your original 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

#15

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 different modules are loaded in LTO configuration with the same
LLVMContext, types with the same name from different modules are renamed so
their names are unique (%struct.foobar in the second module becomes
%struct.foobar.0). After renaming intrinsic names and signatures can become
inconsistent.

This seems like a clear bug in the module loading. If we're changing type
names, we need to change the intrinsic signatures as well.

Usually it slips unnoticed because we don't verify individual modules and
eventually map isomorphic types to a single type. So isomorphic types get
their original names. Although in some cases it causes problems.

Initially I came across the problem with my recent change which added an
overloaded type to the masked load/store intrinsics
(http://reviews.llvm.org/D17270). The discrepancy between the name and the
signature triggers auto-upgrade bit from my patch converting an incorrect
mangling to the correct one. But later after remapping of isomorphic types
when we return to the original type name this “updated" intrinsic name
become invalid.

Another way to trigger the problem is to have different types with the same
name in different modules. Corresponding test case is attached. In this case
types in different modules will be renamed but the intrinsics from different
modules will have the same name which will be caught by verifier.

As a possible solution we can use AutoUpgrade to handle the situation when
the name of the intrinsic doesn't match with its signature. In such cases we
have to rename the intrinsic. Then during linking if we map some isomorphic
types we have to update intrinsics names. To do that we have to teach
IRMover to update intrinsics signatures according to the types mapping.

Does this sound reasonable? Are there any other alternatives?

Given our current intrinsic naming scheme, the approach you've described
seems entirely reasonable.

An alternate scheme would be to make the intrinsic signatures insensitive to
the struct naming. (That was probably a bad idea on my part to start with,
sorry!) I would argue that we should not block your original 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*>)

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

#16

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

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

#17

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

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

#18

Sounds good to me too.

Cheers,
Rafael