This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: combine_givs_p address cost
- To: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>, rth at cygnus dot com
- Subject: Re: combine_givs_p address cost
- From: Richard Henderson <rth at cygnus dot com>
- Date: Sat, 21 Nov 1998 21:16:36 -0800
- Cc: egcs at cygnus dot com
- References: <13911.15192.732902.266935@ongaonga.elec.canterbury.ac.nz>
- Reply-To: Richard Henderson <rth at cygnus dot com>
On Sun, Nov 22, 1998 at 11:33:03AM +1300, Michael Hayes wrote:
> The following loop.c patch of Fri Jul 17 14:18:14 1998 to ignore the
> address cost in combine_givs_p pessimises code for the C4x and
> probably other machines that have autoincrement addressing modes.
Yes, well, it only does so for small loops such as the one you've
given. More specific data can be had from Toon. Who primarily
uses m68k, so some experience with autoinc is had.
The problem with that test is that it decides, with no surrounding
context, whether the giv should be combined. Now suppose there are
twenty givs that could be combined instead of two. Failing to allow
their combination means we'll have oodles of spills and oodles of
increments where offsets from one register would have sufficed.
This problem, and similar problems in sched1, could both be solved
if we had a resonably accurate picture of what resource pressure
looks like at any point in the function, and had some idea what steps
to take to reduce that pressure. Or, as you point out, to notice
that we can do better by using more of the resources that are still
available. Without such a model, I'm not sure what we can do to
intelligently address this problem.
If you have specific suggestions for heuristics, I'm quite willing
to discuss them. And we can always try them out on various problem
sets to see how they do.
r~