llvm dev - Oct 2014 - [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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141026/bf0205a1/attachment.html>

----- 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

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.