public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Meissner <meissner@linux.ibm.com>,
	gcc-patches@gcc.gnu.org,        dje.gcc@gmail.com
Subject: Re: [PATCH], PR Fix floatsi{sf,df}2 and floatunssi{sf,df}2 for a future powerpc machine
Date: Fri, 28 Jun 2019 11:32:00 -0000	[thread overview]
Message-ID: <20190628113224.GW7313@gate.crashing.org> (raw)
In-Reply-To: <20190627164900.GA11074@ibm-toto.the-meissners.org>

Hi Mike,

On Thu, Jun 27, 2019 at 12:49:00PM -0400, Michael Meissner wrote:
> As I detail in PR 91009, I had some testsuite failures with my patches for a
> future machine.  In the future patches, I added new RTL attributes to support
> the new prefixed load/store instructions (which will include pc-relative
> support).  This new attribute needs to look at the 'type' RTL attribute, and
> that in turn depends on doing a constrain operands to determine whether the
> insn is a load, store, or add instruction.
> 
> This constrain operands call occurs before the first split pass.  The insns
> that convert SImode to SFmode or DFmode which are split in the first pass,
> currently use the "wa" constraint for the floating point result.  Unfortunately
> if the user uses the -mno-vsx option, the "wa" constraint becomes NO_REGS.

Yes, constrain_operands is called very early.  It's called during combine
for pretty much all insns, but it's already called by ifcvt ("ce1", the
eighth or so RTL pass) for some.  Instruction costing needs to figure out
which instruction alternatives are enabled, and which not.

> This patch is a rather limited patch that just adds an alternative using the
> "d" constraint, so there is a valid alternative before splitting.

The "before splitting" isn't really relevant: you have to have some
alternative enabled for all insns you generate.  Because lfiwax (the
machine instruction after which this pattern is named) only works on
floating point registers, not all VSX registers, and this pattern is
generated from places that do not check if VSX is enabled, adding a
"d" alternative sounds good yes.

> This patch does not do the cleanup mentioned in PR 90822.  That will still be
> done, but I wanted to fix the actual problem before doing the next iteration of
> the code cleanup.
> 
> I have done a bootstrap and make check, and there were no regressions.  Can I
> check this into the trunk?

[ Please mention on what kind of system, what configuration.  This matters
  when things go wrong.  Something like "powerpc64le-linux, power8" is
  enough info usually, if you used default configurations. ]

> 2019-06-27   Michael Meissner  <meissner@linux.ibm.com>
> 
> 	PR target/91009
> 	* config/rs6000/rs6000.md (floatsi<mode>2_lfiwax): Add non-VSX
> 	alternative.
> 	(floatsi<mode>2_lfiwax_mem): Add non-VSX alternative.
> 	(floatunssi<mode>2_lfiwzx): Add non-VSX alternative.
> 	(floatunssi<mode>2_lfiwzx_mem): Add non-VSX alternative.

The patch is fine for trunk.  Thanks Mike.


Segher

      reply	other threads:[~2019-06-28 11:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27 16:49 Michael Meissner
2019-06-28 11:32 ` Segher Boessenkool [this message]

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=20190628113224.GW7313@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=meissner@linux.ibm.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).