This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: 4.2 reload infrastructure to fix PR target/21623
- From: Bernd Schmidt <bernds_cb1 at t-online dot de>
- To: Joern Rennecke <amylaar at spamcop dot net>
- Cc: Joern RENNECKE <joern dot rennecke at st dot com>, Ian Lance Taylor <ian at airs dot com>, gcc-patches at gcc dot gnu dot org, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, aoliva at redhat dot com
- Date: Sun, 09 Oct 2005 15:32:43 +0200
- Subject: Re: RFA: 4.2 reload infrastructure to fix PR target/21623
- References: <20051008140410.1fruo4cgswggs0co@webmail.spamcop.net>
Joern Rennecke wrote:
In http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00441.html, Berndt Schmiodt
wrote:
Thanks for tackling this problem. Couple of comments on the patch - on the
whole I think this is looking pretty good.
Note that I've given an alternate interface proposal in my last reply to
Tan Taylor: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00438.html
Yes, I saw that, but I'm not sure how workable it is:
Not sure I agree with the comments about recursion. Isn't there a mismatch
between what targetm.secondary_reload_class wants (an rtx) and what we can give
it (an intermediate class and mode)?
Any comments?
I've enumerated a couple of things earlier in this thread:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00099.html
Ok. Let's not overdesign it, however. I dread an attempt to make
lifetimes more accurate with the current set of RELOAD_FOR_FOO lifetime
descriptions.
Does the sh need multiple intermediate registers for any of its secondary
reloads?
Yes, that is what originally started this thread. In order to copy the
T register to FP_REGS, the copy has to go through GENERAL_REGS and FPUL_REGS.
How common is this?
However, if we don't describe intermediate registers as they are and
allow to use them to reduce more comples reload problems to simpler reload
problems, the coding effort for a port maintainer is quadratic with the
length of the chain of copies needed. Moreover, these unnecessaryly large
reload patterns make the process harder to understand.
I'd say it depends how often we need something like this. If it's only
a rare one-off case in the sh backend, then I think we're better off
just slightly extending the current scheme along the lines of the patch
you posted. If it happens more frequently for more ports, then it might
be warranted to look for another approach, but the interface will be
quite different from what we have now.
Having the ability to use separate patterns for different needs should
already help with the understandability, shouldn't it?
Bernd