public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Steve Ellcey <sellcey@cavium.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch 4/4][Aarch64] v2: Implement Aarch64 SIMD ABI
Date: Thu, 06 Dec 2018 12:25:00 -0000	[thread overview]
Message-ID: <87tvjq3kqs.fsf@arm.com> (raw)
In-Reply-To: <1541699749.12016.9.camel@cavium.com> (Steve Ellcey's message of	"Thu, 8 Nov 2018 17:55:50 +0000")

Steve Ellcey <sellcey@cavium.com> writes:
> This is a patch 4 to support the Aarch64 SIMD ABI [1] in GCC.
>
> It defines a new target hook targetm.check_part_clobbered that
> takes a rtx_insn and checks to see if it is a call to a function
> that may clobber partial registers.  It returns true by default,
> which results in the current behaviour, but if we can determine
> that the function will not do any partial clobbers (like the
> Aarch64 SIMD functions) then it returns false.

Sorry, have a feeling this is going to be at least partly going
back on what I said before, but...

The patch only really deals with one user of the part-clobbered info,
namely LRA.  And as it happens, that caller does have access to the
relevant call insns (which was a concern before), since you walk them in:

  /* Check to see if any call might do a partial clobber.  */
  partial_clobber_in_bb = false;
  FOR_BB_INSNS_REVERSE_SAFE (bb, curr_insn, next)
    {
      if (CALL_P (curr_insn)
          && targetm.check_part_clobbered (curr_insn))
        {
          partial_clobber_in_bb = true;
          break;
        }
    }

Since we're looking at the call insns anyway, we could have a hook that
"jousts" two calls and picks the one that preserves *fewer* registers.
This would mean that loop produces a single instruction that conservatively
describes the call-preserved registers.  We could then stash that
instruction in lra_reg instead of the current check_part_clobbered
boolean.

The hook should by default be a null pointer, so that we can avoid
the instruction walk on targets that don't need it.

That would mean that LRA would always have a call instruction to hand
when asking about call-preserved information.  So I think we should
add an insn parameter to targetm.hard_regno_call_part_clobbered,
with a null insn selecting the defaul behaviour.   I know it's
going to be a pain to update all callers and targets, sorry.

This would also cope with the fact that, when SVE is enabled, SIMD
functions *do* still part-clobber the registers, just in a wider mode.
The current patch doesn't handle that, and it would be hard to fix without
pessimistically treating the functions as clobbering above 64 bits
rather 128 bits.

(Really, it would be good to overhaul the whole handling of ABIs
so that we have all the information about an ABI in one structure
and can ask "what ABI does this call use"?  But that's a lot of work.
The above should be good enough as long as the call-preserved behaviour
of ABIs follows a total ordering, which it does for AArch64.)

Thanks,
Richard

  reply	other threads:[~2018-12-06 12:25 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 [this message]
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
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=87tvjq3kqs.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=sellcey@cavium.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).