public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Steve Ellcey <sellcey@marvell.com>
Cc: "sellcey\@cavium.com" <sellcey@cavium.com>,
	 "gcc-patches\@gcc.gnu.org"	<gcc-patches@gcc.gnu.org>,
	rguenther@suse.de, jakub@redhat.com
Subject: Re: [Patch 4/4][Aarch64] v2: Implement Aarch64 SIMD ABI
Date: Fri, 11 Jan 2019 11:23:00 -0000	[thread overview]
Message-ID: <87ef9j30bw.fsf@arm.com> (raw)
In-Reply-To: <1faa09dc8a758006fc373f6e4296ea1d5c39043d.camel@marvell.com>	(Steve Ellcey's message of "Fri, 11 Jan 2019 00:13:27 +0000")

Steve Ellcey <sellcey@marvell.com> writes:
> OK, I fixed the issues in your last email.  I initially found one
> regression while testing.  In lra_create_live_ranges_1 I had removed
> the 'call_p = false' statement but did not replaced it with anything.
> This resulted in no regressions on aarch64 but caused a single
> regression on x86 (gcc.target/i386/pr87759.c).  I replaced the
> line with 'call_insn = NULL' and the regression went away so I
> have clean bootstraps and no regressions on aarch64 and x86 now.

Looks good to me bar the parameter description below.

> If this looks good to you can I go ahead and check it in?  I know
> we are in Stage 3 now, but my recollection is that patches that were
> initially submitted during Stage 1 could go ahead once approved.

Yeah, like you say, this was originally posted in stage 1 and is the
last patch in the series.  Not committing it would leave the work
incomplete in GCC 9.  The problem is that we're now in stage 4 rather
than stage 3.

I don't think I'm neutral enough to make the call.  Richard, Jakub?

> diff --git a/gcc/lra-lives.c b/gcc/lra-lives.c
> index a00ec38..b77b675 100644
> --- a/gcc/lra-lives.c
> +++ b/gcc/lra-lives.c
> @@ -576,25 +576,39 @@ lra_setup_reload_pseudo_preferenced_hard_reg (int regno,
>  
>  /* Check that REGNO living through calls and setjumps, set up conflict
>     regs using LAST_CALL_USED_REG_SET, and clear corresponding bits in
> -   PSEUDOS_LIVE_THROUGH_CALLS and PSEUDOS_LIVE_THROUGH_SETJUMPS.  */
> +   PSEUDOS_LIVE_THROUGH_CALLS and PSEUDOS_LIVE_THROUGH_SETJUMPS.
> +   CALL_INSN may be the specific call we want to check that REGNO lives
> +   through or a call that is guaranteed to clobber REGNO if any call
> +   in the current block clobbers REGNO.  */

I think it would be more accurate to say:

   CALL_INSN is a call that is representative of all calls in the region
   described by the PSEUDOS_LIVE_THROUGH_* sets, in terms of the registers
   that it preserves and clobbers.  */

> +
>  static inline void
>  check_pseudos_live_through_calls (int regno,
> -				  HARD_REG_SET last_call_used_reg_set)
> +				  HARD_REG_SET last_call_used_reg_set,
> +				  rtx_insn *call_insn)
>  {
>    int hr;
> +  rtx_insn *old_call_insn;
>  
>    if (! sparseset_bit_p (pseudos_live_through_calls, regno))
>      return;
> +
> +  gcc_assert (call_insn && CALL_P (call_insn));
> +  old_call_insn = lra_reg_info[regno].call_insn;
> +  if (!old_call_insn
> +      || (targetm.return_call_with_max_clobbers
> +	  && targetm.return_call_with_max_clobbers (old_call_insn, call_insn)
> +	     == call_insn))
> +    lra_reg_info[regno].call_insn = call_insn;
> +
>    sparseset_clear_bit (pseudos_live_through_calls, regno);
>    IOR_HARD_REG_SET (lra_reg_info[regno].conflict_hard_regs,
>  		    last_call_used_reg_set);
>  
>    for (hr = 0; HARD_REGISTER_NUM_P (hr); hr++)
> -    if (targetm.hard_regno_call_part_clobbered (hr,
> +    if (targetm.hard_regno_call_part_clobbered (call_insn, hr,
>  						PSEUDO_REGNO_MODE (regno)))
>        add_to_hard_reg_set (&lra_reg_info[regno].conflict_hard_regs,
>  			   PSEUDO_REGNO_MODE (regno), hr);
> -  lra_reg_info[regno].call_p = true;
>    if (! sparseset_bit_p (pseudos_live_through_setjumps, regno))
>      return;
>    sparseset_clear_bit (pseudos_live_through_setjumps, regno);

BTW, I think we could save some compile time by moving the "for" loop
into the new "if", since otherwise call_insn should have no new
information.  But that was true before as well (since we could have
skipped the loop if lra_reg_info[regno].call_p was already true),
so it's really a separate issue.

Thanks,
Richard

  reply	other threads:[~2019-01-11 11:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08 17:55 Steve Ellcey
2018-12-06 12:25 ` Richard Sandiford
2019-01-04 23:57   ` Steve Ellcey
2019-01-07 17:39     ` Richard Sandiford
2019-01-08 23:42       ` Steve Ellcey
2019-01-09 10:01         ` Richard Sandiford
2019-01-10  0:19           ` Steve Ellcey
2019-01-10  9:16             ` Richard Sandiford
2019-01-11  0:13               ` Steve Ellcey
2019-01-11 11:23                 ` Richard Sandiford [this message]
2019-01-11 11:30                   ` Jakub Jelinek
2019-01-11 14:03                     ` [EXT] " Steve Ellcey

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=87ef9j30bw.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=rguenther@suse.de \
    --cc=sellcey@cavium.com \
    --cc=sellcey@marvell.com \
    /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).