public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bill Schmidt <wschmidt@linux.ibm.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com
Subject: Re: [PATCH 11/18] rs6000: Builtin expansion, part 6
Date: Sun, 7 Nov 2021 09:28:09 -0600	[thread overview]
Message-ID: <ae5330e2-2a74-ff2a-e391-2f004bac9854@linux.ibm.com> (raw)
In-Reply-To: <20211104012419.GJ614@gate.crashing.org>

Hi Segher,

Thank you for all of the reviews!  I appreciate your hard work and thorough 
study of the patches.

I've updated these 6 patches and combined them into 1, pushed today.  There 
are still a couple of cleanups I haven't done, but I made note in the code
where these are needed.

Thanks again!
Bill

On 11/3/21 8:24 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 01, 2021 at 11:13:47AM -0500, Bill Schmidt wrote:
>> Provide replacements for htm_spr_num and htm_expand_builtin.  No logic
>> changes are intended here, as usual.  Much code was factored out into
>> rs6000_expand_new_builtin, so the new version of htm_expand_builtin is
>> a little tidier.
> Nice.
>
>> Also implement the support for the "endian" and "32bit" attributes,
>> which is straightforward.  These just do icode substitution.
> Don't call this "attributes" please?  I don't know what would be a
> better name, of course.  "bif attribute" maybe?
>
>> +  rtx op[MAX_HTM_OPERANDS], pat;
> Don't declare arrays and scalars in the same statement, in general.  It
> is important that the arrays stand out.
>
> Also, don't declare things before they are used please.
>
>> +  FOR_EACH_CALL_EXPR_ARG (arg, iter, exp)
>> +    {
>> +      if (arg == error_mark_node || nopnds >= MAX_HTM_OPERANDS)
>> +	return const0_rtx;
>> +
>> +      insn_op = &insn_data[icode].operand[nopnds];
>> +      op[nopnds] = expand_normal (arg);
>> +
>> +      if (!insn_op->predicate (op[nopnds], insn_op->mode))
>> +	{
>> +	  if (!strcmp (insn_op->constraint, "n"))
>> +	    {
>> +	      int arg_num = (nonvoid) ? nopnds : nopnds + 1;
> Please don't parenthesise random expressions like "nonvoid".  I wonder
> if that can be simpler handled by just unshifting a void_node into the
> operands, btw :-)
>
> And the same "n" thing as before of course.  Since it is the same: some
> factoring would be helpful probably.
>
>> +      machine_mode mode = (TARGET_POWERPC64) ? DImode : SImode;
> Superfluous parens.  This is just "word_mode", anyway?
>
>> +  /* If this builtin accesses a CR, then pass in a scratch
>> +     CR as the last operand.  */
>> +  else if (bif_is_htmcr (*bifaddr))
>> +    {
>> +      cr = gen_reg_rtx (CCmode);
>> +      op[nopnds++] = cr;
>> +    }
> There is only one CR ("condition register").  You can say CRF here
> ("condition register field", a 4-bit thing), or just cc or CC maybe
> ("condition code").  A pet peeve, I know.
>
>> +  if (bif_is_endian (*bifaddr) && BYTES_BIG_ENDIAN)
> "is_endian" should maybe be "is_bigendian" or something like that?
>
> Okay for trunk with the changes you see fit at this time.  Thanks!
>
>
> Segher

  reply	other threads:[~2021-11-07 15:28 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01 16:13 [PATCHv5 00/18] Replace the Power target-specific builtin machinery Bill Schmidt
2021-09-01 16:13 ` [PATCH 01/18] rs6000: Handle overloads during program parsing Bill Schmidt
2021-09-13 17:17   ` will schmidt
2021-09-13 23:53   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 02/18] rs6000: Move __builtin_mffsl to the [always] stanza Bill Schmidt
2021-09-13 17:53   ` will schmidt
2021-09-16 22:52   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 03/18] rs6000: Handle gimple folding of target built-ins Bill Schmidt
2021-09-13 18:42   ` will schmidt
2021-09-14 22:36     ` Bill Schmidt
2021-09-16 22:58   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 04/18] rs6000: Handle some recent MMA builtin changes Bill Schmidt
2021-09-13 19:02   ` will schmidt
2021-09-16 23:38   ` Segher Boessenkool
2021-09-17 15:14     ` Bill Schmidt
2021-09-01 16:13 ` [PATCH 05/18] rs6000: Support for vectorizing built-in functions Bill Schmidt
2021-09-13 19:29   ` will schmidt
2021-09-17 12:17   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 06/18] rs6000: Builtin expansion, part 1 Bill Schmidt
2021-10-31  3:24   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 07/18] rs6000: Builtin expansion, part 2 Bill Schmidt
2021-11-01 12:18   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 08/18] rs6000: Builtin expansion, part 3 Bill Schmidt
2021-11-03  1:15   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 09/18] rs6000: Builtin expansion, part 4 Bill Schmidt
2021-11-03  1:52   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 10/18] rs6000: Builtin expansion, part 5 Bill Schmidt
2021-11-04  0:55   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 11/18] rs6000: Builtin expansion, part 6 Bill Schmidt
2021-11-04  1:24   ` Segher Boessenkool
2021-11-07 15:28     ` Bill Schmidt [this message]
2021-11-07 21:05       ` Segher Boessenkool
2021-11-08 13:16         ` Bill Schmidt
2021-09-01 16:13 ` [PATCH 12/18] rs6000: Update rs6000_builtin_decl Bill Schmidt
2021-11-05 20:27   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 13/18] rs6000: Miscellaneous uses of rs6000_builtins_decl_x Bill Schmidt
2021-11-05 20:36   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 14/18] rs6000: Debug support Bill Schmidt
2021-11-05 21:34   ` Segher Boessenkool
2021-11-09 15:06     ` Bill Schmidt
2021-09-01 16:13 ` [PATCH 15/18] rs6000: Update altivec.h for automated interfaces Bill Schmidt
2021-11-05 22:08   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 16/18] rs6000: Test case adjustments Bill Schmidt
2021-11-05 22:37   ` Segher Boessenkool
2021-11-11 20:06     ` Bill Schmidt
2021-11-11 20:55       ` Bill Schmidt
2021-09-01 16:13 ` [PATCH 17/18] rs6000: Enable the new builtin support Bill Schmidt
2021-11-05 22:10   ` Segher Boessenkool
2021-09-01 16:13 ` [PATCH 18/18] rs6000: Add escape-newline support for builtins files Bill Schmidt
2021-11-05 23:50   ` Segher Boessenkool
2021-11-08 19:40     ` Bill Schmidt
2021-09-13 13:33 ` [PATCHv5 00/18] Replace the Power target-specific builtin machinery Bill Schmidt

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=ae5330e2-2a74-ff2a-e391-2f004bac9854@linux.ibm.com \
    --to=wschmidt@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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).