Hi,
I should double check this but I viewed the "." as being useful to
separate different parameter types in case we need to overload on
multiple parameters. I think of p0i32 as the type of a single
parameter. If we had multiple parameters with complex types, I think
it might become harder to read if we separated each component, .e.g.,
a hypothetical intrinsic that takes a vector of 4 of pointers to i32
and vector of 4 of pointers to i64 would look either like
@intrinsic.v4p0i32.v4p0i64
or
@intrinsic.v4.p0.i32.v4.p0.i64
I find the former a little easier to parse. What do you all think?
-- Mon Ping
On Jul 7, 2008, at 2:40 AM, Benedict Gaster wrote:
> Hi,
>
> Great I look forward to the patch!
>
> One comment I had was on the name of the overloaded intrinsics. In
> your example you resolve the atomic.load.add to:
>
> @llvm.atomic.load.add.p0i32 // i32 ptr to default address space
> @llvm.atomic.load.add.p11i32 // i32 ptr to address space 11
>
> and I was wondering could they instead be named:
>
> @llvm.atomic.load.add.p0.i32 // i32 ptr to default address space
> @llvm.atomic.load.add.p11.i32 // i32 ptr to address space 11
>
> For me this is a little easier to read and separates out the type
> components. I expect that there might be an LLVM naming convention
> that I am not aware off, that invalidates my suggestion.
> [Deleted Text]
Yes I agree now that I've seen a more complex example. Ben On 7 Jul 2008, at 20:27, Chris Lattner wrote:> On Mon, 7 Jul 2008, Mon P Wang wrote: >> I should double check this but I viewed the "." as being useful to >> separate different parameter types in case we need to overload on >> multiple parameters. I think of p0i32 as the type of a single >> parameter. If we had multiple parameters with complex types, I think >> it might become harder to read if we separated each component, .e.g., >> a hypothetical intrinsic that takes a vector of 4 of pointers to i32 >> and vector of 4 of pointers to i64 would look either like >> @intrinsic.v4p0i32.v4p0i64 >> or >> @intrinsic.v4.p0.i32.v4.p0.i64 >> >> I find the former a little easier to parse. What do you all think? > > I agree, I prefer the former. > > -Chris > >> On Jul 7, 2008, at 2:40 AM, Benedict Gaster wrote: >> >>> Hi, >>> >>> Great I look forward to the patch! >>> >>> One comment I had was on the name of the overloaded intrinsics. In >>> your example you resolve the atomic.load.add to: >>> >>> @llvm.atomic.load.add.p0i32 // i32 ptr to default address space >>> @llvm.atomic.load.add.p11i32 // i32 ptr to address space 11 >>> >>> and I was wondering could they instead be named: >>> >>> @llvm.atomic.load.add.p0.i32 // i32 ptr to default address >>> space >>> @llvm.atomic.load.add.p11.i32 // i32 ptr to address space 11 >>> >>> For me this is a little easier to read and separates out the type >>> components. I expect that there might be an LLVM naming convention >>> that I am not aware off, that invalidates my suggestion. >>> [Deleted Text] >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Mon, 7 Jul 2008, Mon P Wang wrote:> I should double check this but I viewed the "." as being useful to > separate different parameter types in case we need to overload on > multiple parameters. I think of p0i32 as the type of a single > parameter. If we had multiple parameters with complex types, I think > it might become harder to read if we separated each component, .e.g., > a hypothetical intrinsic that takes a vector of 4 of pointers to i32 > and vector of 4 of pointers to i64 would look either like > @intrinsic.v4p0i32.v4p0i64 > or > @intrinsic.v4.p0.i32.v4.p0.i64 > > I find the former a little easier to parse. What do you all think?I agree, I prefer the former. -Chris> On Jul 7, 2008, at 2:40 AM, Benedict Gaster wrote: > >> Hi, >> >> Great I look forward to the patch! >> >> One comment I had was on the name of the overloaded intrinsics. In >> your example you resolve the atomic.load.add to: >> >> @llvm.atomic.load.add.p0i32 // i32 ptr to default address space >> @llvm.atomic.load.add.p11i32 // i32 ptr to address space 11 >> >> and I was wondering could they instead be named: >> >> @llvm.atomic.load.add.p0.i32 // i32 ptr to default address space >> @llvm.atomic.load.add.p11.i32 // i32 ptr to address space 11 >> >> For me this is a little easier to read and separates out the type >> components. I expect that there might be an LLVM naming convention >> that I am not aware off, that invalidates my suggestion. >> [Deleted Text] > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://nondot.org/sabre/ http://llvm.org/