Demikhovsky, Elena
2014-Oct-26 15:17 UTC
[LLVMdev] Masked vector intrinsics and name mangling
Hal, thank you for your opinion. I just was confused when I saw so long name " llvm.masked.load.v16i32.p0i32.v16i32.i32.v16i1" . If we stay with a short name, we do a step towards instruction form. - Elena -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Sunday, October 26, 2014 17:06 To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Masked vector intrinsics and name mangling ----- Original Message -----> From: "Elena Demikhovsky" <elena.demikhovsky at intel.com> > To: llvmdev at cs.uiuc.edu > Sent: Sunday, October 26, 2014 5:34:46 AM > Subject: [LLVMdev] Masked vector intrinsics and name mangling > > > > Hi, > > The proposed masked vector intrinsics are overloaded - one intrinsic > ID for multiple types. > After name mangling it will look like: > > %res = call <16 x i32> > @llvm.masked.load.v16i32.p0i32.v16i32.i32.v16i1(i32* %addr, <16 x > i32>%passthru, i32 4, <16 x i1> %mask) > 6 types x 3 vector sizes = 18 names for one operation > > I propose to remove name mangling from these intrinsics: > %res = call <16 x i32> @llvm.masked.load (i32* %addr, <16 x > i32>%passthru, i32 4, <16 x i1> %mask) > > def int_masked_load : > Intrinsic<[llvm_anyvector_ty], [llvm_anyptr_ty, llvm_anyvector_ty, > llvm_anyint_ty, llvm_anyvector_ty], [IntrReadArgMem, NoNameMangling]>; > // new property > > It will significantly simplify reading and manual writing. > What do you think?We already have this kind of situation for @llvm.memcpy and friends, and while it can make the IR look verbose at times, we have reasonable interfaces for creating and manipulating these at the C++ level, so I don't think it is worthwhile to further complicate the system. -Hal> > Thank you. > > > * Elena > > > > > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
----- Original Message -----> From: "Elena Demikhovsky" <elena.demikhovsky at intel.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu > Sent: Sunday, October 26, 2014 10:17:49 AM > Subject: RE: [LLVMdev] Masked vector intrinsics and name mangling > > Hal, thank you for your opinion. > I just was confused when I saw so long name " > llvm.masked.load.v16i32.p0i32.v16i32.i32.v16i1" . > If we stay with a short name, we do a step towards instruction form.I completely understand, I just don't think it matters all that much, and the logic necessary to handle it will just become a source of bugs (and thus a distraction). You don't need to worry about the exact mangled name when working with the intrinsic at the IR level. Let's get the intrinsic in first, we can always shorten the name later in a backward-compatible fashion if we decide it is worthwhile. I think one could make an argument that the mangling is really unnecessary on all of the intrinsics, and maybe this is an improvement worth making, but I think we should deal with it as a separate matter. Thanks again, Hal> > > - Elena > > > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Sunday, October 26, 2014 17:06 > To: Demikhovsky, Elena > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Masked vector intrinsics and name mangling > > ----- Original Message ----- > > From: "Elena Demikhovsky" <elena.demikhovsky at intel.com> > > To: llvmdev at cs.uiuc.edu > > Sent: Sunday, October 26, 2014 5:34:46 AM > > Subject: [LLVMdev] Masked vector intrinsics and name mangling > > > > > > > > Hi, > > > > The proposed masked vector intrinsics are overloaded - one > > intrinsic > > ID for multiple types. > > After name mangling it will look like: > > > > %res = call <16 x i32> > > @llvm.masked.load.v16i32.p0i32.v16i32.i32.v16i1(i32* %addr, <16 x > > i32>%passthru, i32 4, <16 x i1> %mask) > > 6 types x 3 vector sizes = 18 names for one operation > > > > I propose to remove name mangling from these intrinsics: > > %res = call <16 x i32> @llvm.masked.load (i32* %addr, <16 x > > i32>%passthru, i32 4, <16 x i1> %mask) > > > > def int_masked_load : > > Intrinsic<[llvm_anyvector_ty], [llvm_anyptr_ty, llvm_anyvector_ty, > > llvm_anyint_ty, llvm_anyvector_ty], [IntrReadArgMem, > > NoNameMangling]>; > > // new property > > > > It will significantly simplify reading and manual writing. > > What do you think? > > We already have this kind of situation for @llvm.memcpy and friends, > and while it can make the IR look verbose at times, we have > reasonable interfaces for creating and manipulating these at the C++ > level, so I don't think it is worthwhile to further complicate the > system. > > -Hal > > > > > Thank you. > > > > > > * Elena > > > > > > > > > > > > --------------------------------------------------------------------- > > Intel Israel (74) Limited > > > > This e-mail and any attachments may contain confidential material > > for > > the sole use of the intended recipient(s). Any review or > > distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
> On Oct 26, 2014, at 8:22 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- >> From: "Elena Demikhovsky" <elena.demikhovsky at intel.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Sunday, October 26, 2014 10:17:49 AM >> Subject: RE: [LLVMdev] Masked vector intrinsics and name mangling >> >> Hal, thank you for your opinion. >> I just was confused when I saw so long name " >> llvm.masked.load.v16i32.p0i32.v16i32.i32.v16i1" . >> If we stay with a short name, we do a step towards instruction form. > > I completely understand, I just don't think it matters all that much, and the logic necessary to handle it will just become a source of bugs (and thus a distraction). You don't need to worry about the exact mangled name when working with the intrinsic at the IR level. Let's get the intrinsic in first, we can always shorten the name later in a backward-compatible fashion if we decide it is worthwhile. I think one could make an argument that the mangling is really unnecessary on all of the intrinsics, and maybe this is an improvement worth making, but I think we should deal with it as a separate matter.I agree with Hal on both points here. It's worth discussing how to remove mangling for all intrinsics, but that should be a separate discussion. +1 for the proposed intrinsics Philip> > Thanks again, > Hal > >> >> >> - Elena >> >> >> -----Original Message----- >> From: Hal Finkel [mailto:hfinkel at anl.gov] >> Sent: Sunday, October 26, 2014 17:06 >> To: Demikhovsky, Elena >> Cc: llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] Masked vector intrinsics and name mangling >> >> ----- Original Message ----- >>> From: "Elena Demikhovsky" <elena.demikhovsky at intel.com> >>> To: llvmdev at cs.uiuc.edu >>> Sent: Sunday, October 26, 2014 5:34:46 AM >>> Subject: [LLVMdev] Masked vector intrinsics and name mangling >>> >>> >>> >>> Hi, >>> >>> The proposed masked vector intrinsics are overloaded - one >>> intrinsic >>> ID for multiple types. >>> After name mangling it will look like: >>> >>> %res = call <16 x i32> >>> @llvm.masked.load.v16i32.p0i32.v16i32.i32.v16i1(i32* %addr, <16 x >>> i32>%passthru, i32 4, <16 x i1> %mask) >>> 6 types x 3 vector sizes = 18 names for one operation >>> >>> I propose to remove name mangling from these intrinsics: >>> %res = call <16 x i32> @llvm.masked.load (i32* %addr, <16 x >>> i32>%passthru, i32 4, <16 x i1> %mask) >>> >>> def int_masked_load : >>> Intrinsic<[llvm_anyvector_ty], [llvm_anyptr_ty, llvm_anyvector_ty, >>> llvm_anyint_ty, llvm_anyvector_ty], [IntrReadArgMem, >>> NoNameMangling]>; >>> // new property >>> >>> It will significantly simplify reading and manual writing. >>> What do you think? >> >> We already have this kind of situation for @llvm.memcpy and friends, >> and while it can make the IR look verbose at times, we have >> reasonable interfaces for creating and manipulating these at the C++ >> level, so I don't think it is worthwhile to further complicate the >> system. >> >> -Hal >> >>> >>> Thank you. >>> >>> >>> * Elena >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> Intel Israel (74) Limited >>> >>> This e-mail and any attachments may contain confidential material >>> for >>> the sole use of the intended recipient(s). Any review or >>> distribution >>> by others is strictly prohibited. If you are not the intended >>> recipient, please contact the sender and delete all copies. >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> -- >> Hal Finkel >> Assistant Computational Scientist >> Leadership Computing Facility >> Argonne National Laboratory >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev