From: Jeff Law <law@redhat.com>
To: Wilco Dijkstra <wdijkstr@arm.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Fix IRA register preferencing
Date: Tue, 09 Dec 2014 23:17:00 -0000 [thread overview]
Message-ID: <54878309.6070408@redhat.com> (raw)
In-Reply-To: <000b01d013e5$4bc87010$e3595030$@com>
On 12/09/14 12:21, Wilco Dijkstra wrote:
> This fixes a bug in register preferencing. When live range splitting creates a new register from
> another, it copies most fields except for the register preferences. The preference GENERAL_REGS is
> used as reg_pref[i].prefclass is initialized with GENERAL_REGS in allocate_reg_info () and
> resize_reg_info ().
>
> This initialization value is not innocuous like the comment suggests - if a new register has a
> non-integer mode, it is forced to prefer GENERAL_REGS. This changes the register costs in pass 2 so
> that they are incorrect. As a result the liverange is either spilled or allocated to an integer
> register:
>
> void g(double);
> void f(double x)
> {
> if (x == 0)
> return;
> g (x);
> g (x);
> }
>
> f:
> fcmp d0, #0.0
> bne .L6
> ret
> .L6:
> stp x19, x30, [sp, -16]!
> fmov x19, d0
> bl g
> fmov d0, x19
> ldp x19, x30, [sp], 16
> b g
>
> With the fix it uses a floating point register as expected. Given a similar issue in
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html, would it not be better to change the
> initialization values of reg_pref to illegal register classes so this kind of issue can be trivially
> found with an assert? Also would it not be a good idea to have a single register copy function that
> ensures all data is copied?
But there are other times when you really don't want to copy, say when
the original had a small class, but the copy can go into a larger class.
I banged my head on this when I was doing similar work on range
splitting a few years back and ended up recomputing the preferred and
alternate class information. That was much better than copying the
classes.
I pondered heuristics to expand the preferred class, but never
implemented anything IIRC. A trivial heuristic would be to bump to the
next larger class if the given class was a singleton, otherwise copy the
class.
The obvious counter to that heuristic is an allocno that has two ranges
(or N ranges) where we would prefer a different singleton class for each
range. In fact, I'm pretty sure I ran into this kind of situation and
that led me down the "just recompute it" path.
I'd hazard a guess that the simple heuristic would do better than what
we're doing now with GENERAL_REGS though or what you're doing with copying.
jeff
next prev parent reply other threads:[~2014-12-09 23:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 19:21 Wilco Dijkstra
2014-12-09 23:17 ` Jeff Law [this message]
2014-12-10 13:26 ` Wilco Dijkstra
2014-12-10 20:47 ` Jeff Law
2015-04-27 15:01 ` Wilco Dijkstra
2015-11-10 13:31 Wilco Dijkstra
2015-11-12 3:44 ` Vladimir Makarov
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=54878309.6070408@redhat.com \
--to=law@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=wdijkstr@arm.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).