From: David Edelsohn <dje.gcc@gmail.com>
To: GCC Patches <gcc-patches@gcc.gnu.org>, Alan Modra <amodra@gmail.com>
Subject: Re: [RS6000] Fix PR61098, Poor code setting count register
Date: Sat, 24 May 2014 16:26:00 -0000 [thread overview]
Message-ID: <CAGWvnymB3c=HfYTWTT23TJH3QPMA4qis18OvX9H2r10Mjy8Xew@mail.gmail.com> (raw)
In-Reply-To: <20140523152342.GE5162@bubble.grove.modra.org>
On Fri, May 23, 2014 at 11:23 AM, Alan Modra <amodra@gmail.com> wrote:
> OK, let's start again from scratch. This patch fixes PR61098, a
> problem caused by trying to do arithmetic on the count register. The
> fix is to provide a new pseudo in rs6000_emit_set_long_const so
> arithmetic will be done in a gpr.
>
> Additionally, the patch fixes a number of other bugs and cleanup
> issues with rs6000_emit_set_{,long_}const.
>
> - rs6000_emit_set_long_const took two HWI constant parameters, a relic
> from the days when HWI might be 32 bits on powerpc. We're only
> setting a 64-bit value, so remove the unnecessary parameter.
>
> - The !TARGET_POWERPC64 handling of DImode assumed a 32 bit HWI, and
> the insn setting the low 32-bit reg was wrongly marked with a
> reg_equiv note saying the reg contained the entire 64-bit constant.
> I hadn't spotted the bad reg_equiv when writing the previous patch.
>
> - The comments describing the functions are inaccurate and misleading.
>
> - rs6000_emit_set_long_const always returns DEST, so it's caller can
> assume this and rs6000_emit_set_long_const return void.
>
> - The code testing for a NULL DEST in rs6000_emit_set_const is dead.
> DEST cannot be NULL, since the three uses of the function are in
> rs6000.md splitters where DEST (operand[0]) satisfies
> gpc_reg_operand.
>
> - The above two points mean that rs6000_emit_set_const always returns
> DEST, which in turn would allow rs6000_emit_set_const to return
> void. However, in view of a possible future change that might need
> to return status on whether rs6000_emit_set_const emitted anything,
> return a bool.
>
> - rs6000_emit_set_const parameter N is currently unused, and MODE
> always matches GET_MODE (DEST), so N and MODE can be removed.
>
> - The code is liberally sprinkled with copy_rtx. DEST/TEMP is always
> used once without copy_rtx, but which insn uses copy_rtx varies. I
> changed the code to always use a bare DEST as the last insn for
> consistency. (Writing the code this way might allow us to omit the
> copy_rtx on DEST/TEMP entirely. Before reload TEMP will be a new
> pseudo reg, thus doesn't need copy_rtx, and after reload we
> shouldn't have a SUBREG DEST. I wasn't sure of exactly what might
> happen during reload, so left well enough alone.)
>
> Bootstrapped and regression tested powerpc64-linux. OK to apply
> mainline?
This is a much clearer start. Thanks for the revised version.
This is okay.
Thanks, David
prev parent reply other threads:[~2014-05-24 16:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 1:49 Alan Modra
2014-05-08 13:48 ` David Edelsohn
2014-05-09 2:41 ` Alan Modra
2014-05-11 2:24 ` David Edelsohn
2014-05-11 22:53 ` Alan Modra
2014-05-11 23:39 ` Alan Modra
2014-05-14 3:05 ` Alan Modra
2014-05-14 3:46 ` David Edelsohn
2014-05-14 9:56 ` Alan Modra
2014-05-14 21:27 ` David Edelsohn
2014-05-23 15:23 ` Alan Modra
2014-05-24 16:26 ` David Edelsohn [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='CAGWvnymB3c=HfYTWTT23TJH3QPMA4qis18OvX9H2r10Mjy8Xew@mail.gmail.com' \
--to=dje.gcc@gmail.com \
--cc=amodra@gmail.com \
--cc=gcc-patches@gcc.gnu.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).