From: Andrew Stubbs <ams@codesourcery.com>
To: gcc mailing list <gcc@gcc.gnu.org>
Subject: Register allocation problem
Date: Tue, 12 Dec 2023 13:30:20 +0000 [thread overview]
Message-ID: <0ce574c1-ff58-4b8e-a51d-e52143df4b33@codesourcery.com> (raw)
Hi all,
I'm trying to solve an infinite loop in the "reload" pass (LRA). I need
early-clobber on my load instructions and it goes wrong when register
pressure is high.
Is there a proper way to fix this? Or do I need to do something "hacky"
like fixing a register for use with reloads?
Here's the background .....
AMD GCN has a thing called XNACK mode in which load instructions can be
interrupted (by a page miss, for example) and therefore need to be
written such that they are "restartable". This basically means that the
output must not overwrite the input registers (it can happen that a load
is partially successful, especially for vectors, but I believe
overwriting the address and offsets is never safe, even for scalars). Up
to now we've not needed this mode, but it will be needed for Unified
Shared Memory (and theoretically for APU devices).
So I have added new alternatives into my machine description that use
early-clobber set:
[v ,RF ;flat ,* ,12,* ,off] flat_load%o1\t%0, %A1%O1%g1
[&v ,RF ;flat ,* ,12,* ,on ] ^
(The "on" and "off" represent the XNACK mode.)
LRA then generates a register "Assignment" section in the dump, but it's
not happy for some reason and generates another, and another, each with
more and more pseudo registers and insns, and it goes on forever until
the dump file is gigabytes and I kill it.
This is a vague description, sorry, because I don't really understand
what's going on here and the dump files are huge with tens of thousands
of pseudo registers to wade through. I'm hoping somebody recognises the
issue without me spending days on it.
I have a workaround because there's no known failure on devices that
have the AVGPR register file (they use it as spill space and therefore
don't need the memory loads) and I actually don't need XNACK on the
older devices at this time, but probably this is just pushing the
problem further down the road so if there's a better solution then I'd
like to find it.
Thanks in advance
Andrew
next reply other threads:[~2023-12-12 13:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 13:30 Andrew Stubbs [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-05-13 4:10 register " Danish Samad
2002-05-13 18:26 ` Richard Henderson
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=0ce574c1-ff58-4b8e-a51d-e52143df4b33@codesourcery.com \
--to=ams@codesourcery.com \
--cc=gcc@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).