This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 01/10] Fix IRA ICE.
- From: Andrew Stubbs <ams at codesourcery dot com>
- To: Jeff Law <law at redhat dot com>, <gcc-patches at gcc dot gnu dot org>, <richard dot sandiford at arm dot com>
- Date: Mon, 10 Dec 2018 15:21:53 +0000
- Subject: Re: [PATCH 01/10] Fix IRA ICE.
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On 08/12/2018 16:23, Jeff Law wrote:
On 12/8/18 5:14 AM, Richard Sandiford wrote:
Andrew Stubbs <email@example.com> writes:
On 21/11/2018 00:47, Jeff Law wrote:
This seems like a really gross hack and sets an expectation that
generating registers in the target after IRA has started is OK. It is
not OK. THe fact that this works is, IMHO, likely an accident.
What's the proper test for this? Neither lra_in_progress nor
reload_in_progress is set here, and can_create_pseudos returns true.
The patterns have the ability to not generate registers, but they don't
know not to.
Richard Sandiford has stated that it should be OK, but perhaps the other
architectures also work by accident?
Yeah, my understanding was that targets could create new registers here,
and I thought targets did in some situations. But that's also why I'm
suspicious of the patch. If GCN is doing something valid and IRA isn't
coping, then the patch seems to be fixing the problem in the wrong place.
IRA/LRA can create new pseudos internally. What I'm much less sure
about is whether or not the target can create them. WHen IRA/LRA
creates one internally it has the chance to update the various internal
structures it needs. That can't happen with a pseudo created by the
target this late. Vlad would know for sure.
In any case, the new patch series that I will post soon does not appear
to need this patch any more. (I'll post that as soon as I figure out an
unrelated problem with jump threading.)