search for: pni8

...t; On 04/18/2016 10:52 AM, Ahmed Bougacha via llvm-dev wrote: >> >> On Mon, Apr 18, 2016 at 9:45 AM, Artur Pilipenko via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> 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...

...t; 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 po...

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