This is the mail archive of the
mailing list for the GCC project.
Re: [Ping] Re: reload1: detect chained reloads
- From: Ian Lance Taylor <iant at google dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 12 Sep 2006 18:23:33 -0700
- Subject: Re: [Ping] Re: reload1: detect chained reloads
- References: <440F03E7.email@example.com> <200603081625.k28GPEuh031677@greed.delorie.com> <440F155F.firstname.lastname@example.org> <200603081835.k28IZ5GY004959@greed.delorie.com> <440F2E99.email@example.com> <200603082138.k28LchS0008311@greed.delorie.com> <200607311831.k6VIVlRe002018@greed.delorie.com>
DJ Delorie <firstname.lastname@example.org> writes:
> Ping? It's been months, and the m32c port is partly useless without
> this patch.
Sigh, this is such a painful patch. I think it will work correctly,
but it just seems like the wrong way to do it.
Basically, your patch is trying to partially undo the code in
find_reloads which, in the case of multiple RELOAD_FOR_OPERAND_ADDRESS
reloads, converts all RELOAD_FOR_OPADDR_ADDR reloads into
RELOAD_FOR_OPERAND_ADDRESS reloads. You are trying to detect the
association of the reloads after the ordering has been lost.
The reason you want to detect this is that the m32c runs out of reload
I think the right solution, or perhaps I should say the "right"
solution, would be to track the relationship between reloads, or to
clean it up before reload, or to clean it up after reload, or to
handle this case in LEGITIMIZE_RELOAD_ADDRESS.
Still, I can't think of anything your patch will break. So I'll
approve it. I'm approving this patch:
but please remove all the debug stuff and please don't forget the
change mentioned here:
Please change the return type for reloads_unique_chain to "bool".
Please change the name to reloads_unique_chain_p. Please expand the
comment for that function to say something like:
Returns whether R2 and R2 are uniquely chained: the value of one
is used by the other, and that value is not used by any other
reload for this insn. This is used to partially undo the decision
made in find_reloads when in the case of multiple
RELOAD_FOR_OPERAND_ADDRESS reloads it converts all
RELOAD_FOR_OPADDR_ADDR reloads into RELOAD_FOR_OPERAND_ADDRESS
reloads. This code tries to avoid the conflict created by that
change. It might be cleaner to explicitly keep track of which
RELOAD_FOR_OPADDR_ADDR reload is associated with which
RELOAD_FOR_OPERAND_ADDRESS reload, rather than to try to detect
this after the fact.
Please add spaces in "i<=n_reloads".
See if you can add a compile test case for this, although I understand
that that might be difficult.
OK with those changes assuming it still bootstraps and passes the