On 04/19/2016 09:35 AM, Ahmed Bougacha wrote:> On Mon, Apr 18, 2016 at 4:28 PM, Philip Reames > <listmail at philipreames.com> wrote: >> >> >> 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 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?> > And since the backend only distinguishes pointer types based on > addresspace, pNi8 seems sufficient, no? > > -Ahmed
On Tue, Apr 19, 2016 at 1:51 PM, Philip Reames <listmail at philipreames.com> wrote:> > > On 04/19/2016 09:35 AM, Ahmed Bougacha wrote: >> >> On Mon, Apr 18, 2016 at 4:28 PM, Philip Reames >> <listmail at philipreames.com> wrote: >>> >>> >>> >>> 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 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>> >> And since the backend only distinguishes pointer types based on >> addresspace, pNi8 seems sufficient, no? >> >> -Ahmed > >
On 04/19/2016 02:30 PM, Ahmed Bougacha wrote:> On Tue, Apr 19, 2016 at 1:51 PM, Philip Reames > <listmail at philipreames.com> wrote: >> >> On 04/19/2016 09:35 AM, Ahmed Bougacha wrote: >>> On Mon, Apr 18, 2016 at 4:28 PM, Philip Reames >>> <listmail at philipreames.com> wrote: >>>> >>>> >>>> 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 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. :) 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.> > -Ahmed > >>> And since the backend only distinguishes pointer types based on >>> addresspace, pNi8 seems sufficient, no? >>> >>> -Ahmed >>