public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Carl Love <cel@linux.ibm.com>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: gcc-patches@gcc.gnu.org,
	"bergner@linux.ibm.com" <bergner@linux.ibm.com>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	David Edelsohn <dje.gcc@gmail.com>
Subject: Re: [PATCH 2/13] rs6000, Remove __builtin_vsx_xvcvspsxws built-in
Date: Fri, 24 May 2024 13:18:49 -0700	[thread overview]
Message-ID: <9edee8a4-d2e8-4433-b346-1226670fcf71@linux.ibm.com> (raw)
In-Reply-To: <84a8137c-a1ed-eaac-6f1d-a5a54a1a426f@linux.ibm.com>

Kewen:

On 5/14/24 01:43, Kewen.Lin wrote:
> Hi,
> 
> on 2024/4/20 05:17, Carl Love wrote:
>> rs6000, Remove __builtin_vsx_xvcvspsxws built-in
>>
>> The built-in __builtin_vsx_xvcvspsxws is a duplicate of the vec_signed
>> built-in that is documented in the PVIPR.  The __builtin_vsx_xvcvspsxws
>> built-in is not documented and there are no test cases for it.
>>
>> This patch removes the redundant built-in.
> 
> By revisiting the comments on the previous version:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646723.html

The comments from the previous version:
-----------------------------------------------------------------
   I think we should recommend users to adopt the recommended built-ins in
   PVIPR, by checking the corresponding mnemonic in PVIPR, I got:

   __builtin_vsx_xvcvspsxws -> vec_signed
   __builtin_vsx_xvcvspsxds -> N/A
   __builtin_vsx_xvcvspuxds -> N/A
   __builtin_vsx_xvcvdpsxws -> vec_signed{e,o}
   __builtin_vsx_xvcvdpuxws -> vec_unsigned{e,o}
   __builtin_vsx_xvcvdpuxds_uns -> vec_unsigned
   __builtin_vsx_xvcvspdp   -> vec_double{e,o}
   __builtin_vsx_xvcvdpsp   -> vec_float{e,o}
   __builtin_vsx_xvcvspuxws -> vec_unsigned
   __builtin_vsx_xvcvsxwdp  -> vec_double{e,o}
   __builtin_vsx_xvcvuxddp_uns> vec_double

   For __builtin_vsx_xvcvspsxds and __builtin_vsx_xvcvspuxds which don't have
   the according PVIPR built-ins, we can extend the current vec_{un,}signed{e,o}
   to cover them and document them following the section mentioning PVIPR.

are handled by multiple patches in the new series.  The main comment on the previous patch series was to remove most of the built-ins as they were redundant.  So, basically most of the patches in the previous series were thrown out and a new series to remove the built-ins in the current series.
----------------------------------------------------------------------------

That all said, I distinctly remember addressing each of the above built-ins.  The work on the series got
interrupted a couple of times and it looks like some of the patches to address the above got lost.  My bad.
The following is a list of which patch takes care of removing the duplicate built-ins.

__builtin_vsx_xvcvspsxws                     patch 2 removes this built-in
__builtin_vsx_xvcvspsxds -> N/A              patch 4 extends vec_{un,}signede to cover this built-in,
					     Built-in used in rs6000-overload.def.  Built-in now for                           
                                             internal use only.
__builtin_vsx_xvcvspuxds -> N/A              patch 4 extends vec_{un,}signedo to cover this built-in.
					     Built-in used in rs6000-overload.def.  Built-in now for
                                             internal use only 


__builtin_vsx_xvcvdpsxws -> vec_signed{e,o}   removed in patch 4
__builtin_vsx_xvcvdpuxws -> vec_unsigned{e,o} removed in patch 4

__builtin_vsx_xvcvdpuxds_uns -> vec_unsigned  remove in patch 4
__builtin_vsx_xvcvspuxws -> vec_unsigned      remove in patch 4

The following will changes will be put into a new patch when the series is reposted.  It appears they
got lost in the current series.  My bad.

__builtin_vsx_xvcvspdp   -> vec_double{e,o}   remove in new patch number 5
__builtin_vsx_xvcvdpsp   -> vec_float{e,o}    remove in new patch number 5

__builtin_vsx_xvcvsxwdp  -> vec_double{e,o}   remove in new patch number 5
__builtin_vsx_xvcvuxddp_uns> vec_double       remove in new patch number 5

> 
> I wonder if it's intentional to keep the others, at least bifs
> __builtin_vsx_xvcvdpuxds_uns, __builtin_vsx_xvcvspuxws and
> __builtin_vsx_xvcvuxddp_uns looks removable, users can just uses the
> equivalent ones in PVIPR.  And for the others, users can still use
> the PVIPR ones by considering endianness (controlling with endianness
> macros).
> 

Hopefully that makes it clearer where the various changes are.   

The next series will add a new patch 5 in the series.  The remaining patches in this series, patches 5, 6, ... will get moved to patch 6, 7, ... in the next posting of the built-in cleanup patch series.

                            Carl 

  reply	other threads:[~2024-05-24 20:19 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-19 21:04 [PATCH 0/13] rs6000, built-in cleanup patch series Carl Love
2024-04-19 21:16 ` [PATCH 1/13] rs6000, Remove __builtin_vsx_cmple* builtins Carl Love
2024-05-13  6:28   ` Kewen.Lin
2024-04-19 21:17 ` [PATCH 2/13] rs6000, Remove __builtin_vsx_xvcvspsxws built-in Carl Love
2024-05-14  8:43   ` Kewen.Lin
2024-05-24 20:18     ` Carl Love [this message]
2024-05-27  1:43       ` Kewen.Lin
2024-04-19 21:17 ` [PATCH 3/13] rs6000, fix error in unsigned vector float to unsigned int built-in definitions Carl Love
2024-05-14  7:00   ` Kewen.Lin
2024-05-24 20:19     ` Carl Love
2024-04-19 21:17 ` [PATCH 4/13] rs6000, extend the current vec_{un,}signed{e,o} built-ins Carl Love
2024-05-14  7:53   ` Kewen.Lin
2024-05-17 20:20     ` Carl Love
2024-05-20  1:10       ` Kewen.Lin
2024-05-24 20:19     ` Carl Love
2024-04-19 21:17 ` [PATCH 5/13] rs6000, remove duplicated built-ins of vecmergl and vec_mergeh Carl Love
2024-05-14  2:06   ` Kewen.Lin
2024-04-19 21:17 ` [PATCH 6/13] rs6000, add overloaded vec_sel with int128 arguments Carl Love
2024-05-14  2:54   ` Kewen.Lin
2024-05-22  0:13     ` Carl Love
2024-05-22  3:05       ` Kewen.Lin
2024-05-24 20:19         ` Carl Love
2024-04-19 21:18 ` [PATCH 7/13] rs6000, remove the vec_xxsel built-ins, they are duplicates Carl Love
2024-05-14  2:55   ` Kewen.Lin
2024-05-24 20:19     ` Carl Love
2024-04-19 21:18 ` [PATCH 8/13] rs6000, remove __builtin_vsx_vperm_* built-ins Carl Love
2024-05-14  2:59   ` Kewen.Lin
2024-05-24 20:20     ` Carl Love
2024-04-19 21:18 ` [PATCH 9/13] rs6000, remove __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp built-ins Carl Love
2024-05-14  3:01   ` Kewen.Lin
2024-04-19 21:18 ` [PATCH 10/13] rs6000, extend vec_xxpermdi built-in for __int128 args Carl Love
2024-05-14  5:14   ` Kewen.Lin
2024-05-24 20:20     ` Carl Love
2024-04-19 21:18 ` [PATCH 11/13] rs6000, remove __builtin_vsx_xvcmpeqsp_p built-in Carl Love
2024-05-14  5:26   ` Kewen.Lin
2024-05-24 20:20     ` Carl Love
2024-04-19 21:18 ` [PATCH 12/13] rs6000, remove __builtin_vsx_xvcmpeqsp built-in Carl Love
2024-05-14  5:37   ` Kewen.Lin
2024-05-23 18:21     ` Carl Love
2024-05-24 10:43       ` Kewen.Lin
2024-05-24 15:19         ` Carl Love
2024-04-19 21:18 ` [PATCH 13/13] rs6000, remove vector set and vector init built-ins Carl Love
2024-05-14  5:44   ` Kewen.Lin
2024-05-23  0:29     ` Carl Love
2024-05-23  2:27       ` Kewen.Lin
2024-05-10 15:15 ` [PING} Re: [PATCH 0/13] rs6000, built-in cleanup patch series Carl Love

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9edee8a4-d2e8-4433-b346-1226670fcf71@linux.ibm.com \
    --to=cel@linux.ibm.com \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linkw@linux.ibm.com \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).