public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@linaro.org>
To: Jeff Law <law@redhat.com>
Cc: Steve Ellcey <sellcey@cavium.com>,
	 Alan.Hayward@arm.com,
	 "Richard Earnshaw \(lists\)" <Richard.Earnshaw@arm.com>,
	 Francesco Petrogalli <Francesco.Petrogalli@arm.com>,
	 James Greenhalgh <James.Greenhalgh@arm.com>,  "Sekhar\,
	Ashwin" <Ashwin.Sekhar@cavium.com>,  gcc <gcc@gcc.gnu.org>,
	 Marcus Shawcroft <Marcus.Shawcroft@arm.com>,  nd <nd@arm.com>
Subject: Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP
Date: Tue, 29 May 2018 10:06:00 -0000	[thread overview]
Message-ID: <871sdubwv6.fsf@linaro.org> (raw)
In-Reply-To: <a94b6e17-fbf7-1dc3-b65c-cac4b476b06e@redhat.com> (Jeff Law's	message of "Sun, 27 May 2018 09:59:31 -0600")

Jeff Law <law@redhat.com> writes:
> Now that we're in stage1 I do want to revisit the CLOBBER_HIGH stuff.
> When we left things I think we were trying to decide between
> CLOBBER_HIGH and clobbering the appropriate subreg.  The problem with
> the latter is the dataflow we compute is inaccurate (overly pessimistic)
> so that'd have to be fixed.

The clobbered part of the register in this case is a high-part subreg,
which is ill-formed for single registers.  It would also be difficult
to represent in terms of the mode, since there are no defined modes for
what can be stored in the high part of an SVE register.  For 128-bit
SVE that mode would have zero bits. :-)

I thought the alternative suggestion was instead to have:

   (set (reg:M X) (reg:M X))

when X is preserved in mode M but not in wider modes.  But that seems
like too much of a special case to me, both in terms of the source and
the destination:

- On the destination side, a SET normally provides something for later
  instructions to use, whereas here the effect is intended to be the
  opposite: the instruction has no effect at all on a value of mode M
  in X.  As you say, this would pessimise df without specific handling.
  But I think all optimisations that look for the definition of a value
  would need to be taught to "look through" this set to find the real
  definition of (reg:M X) (or any value of a mode no larger than M in X).
  Very few passes use the df def-uses chains for this due its high cost.

- On the source side, the instruction doesn't actually care what's in X,
  but nevertheless appears to use it.  This means that most passes would
  need to be taught that a use of X on the rhs of a no-op SET is special
  and should usually be ignored.

  More fundamentally, it should be possible in RTL to express an
  instruction J that *does* read X in mode M and clobbers its high part.
  If we use the SET above to represent the clobber, and treat the rhs use
  as special, then presumably J would need two uses of X, one "dummy" one
  on the no-op SET and one "real" one on some other SET (or perhaps in a
  top-level USE).  Having the number of uses determine this seems
  a bit awkward.

IMO CLOBBER and SET have different semantics for good reason: CLOBBER
represents an optimisation barrier for things that care about the value
of a certain rtx object, while SET represents a productive effect or
side-effect.  The effect we want here is the same as a normal clobber,
except that the clobber is mode-dependent.

Thanks,
Richard

  reply	other threads:[~2018-05-29 10:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-09 21:47 Steve Ellcey
2018-05-15 18:29 ` Francesco Petrogalli
2018-05-16 16:21   ` Steve Ellcey
2018-05-16 16:30     ` Richard Earnshaw (lists)
2018-05-16 17:30       ` Steve Ellcey
2018-05-16 21:11         ` Richard Sandiford
2018-05-24 17:50           ` Steve Ellcey
2018-05-26 10:09             ` Richard Sandiford
2018-05-26 22:13               ` Segher Boessenkool
2018-05-27 15:59               ` Jeff Law
2018-05-29 10:06                 ` Richard Sandiford [this message]
2018-05-31 10:39                   ` Alan Hayward
2018-06-12  3:11                     ` Jeff Law
2018-06-11 23:06                   ` Jeff Law
2018-07-02 18:16     ` Francesco Petrogalli
  -- strict thread matches above, loose matches on Subject: below --
2017-03-15  9:50 Sekhar, Ashwin
2017-03-17 14:02 ` James Greenhalgh
2017-03-20  4:30   ` Sekhar, Ashwin

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=871sdubwv6.fsf@linaro.org \
    --to=richard.sandiford@linaro.org \
    --cc=Alan.Hayward@arm.com \
    --cc=Ashwin.Sekhar@cavium.com \
    --cc=Francesco.Petrogalli@arm.com \
    --cc=James.Greenhalgh@arm.com \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=nd@arm.com \
    --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).