This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Ping] Re: reload1: detect chained reloads


DJ Delorie <dj@redhat.com> writes:

> Ping?  It's been months, and the m32c port is partly useless without
> this patch.
> 
> http://gcc.gnu.org/ml/gcc-patches/2006-03/threads.html#00047

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
registers otherwise.

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:
    http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00450.html
but please remove all the debug stuff and please don't forget the
change mentioned here:
    http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00465.html

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
testsuite.

Thanks.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]