On 03/09/2011 10:09 AM, Georg-Johann Lay wrote:
Vladimir Makarov schrieb:
On 03/08/2011 06:36 AM, Georg-Johann Lay wrote:
Returning memory move costs 4 times higher (8 instead of 2) for QI
memory moves, IRA/reload generates code as expected.
Is there any other way than lying about the costs?
IRA doues not take into account costs implied by generating new stack
slots and setting up frame pointer. AFAIK there is no hook to
influence that. How can a target describe costs generated by setting
up stack slots and accessing them?
First of all, defining equal costs for moving into memory and into
register (2 in both cases) is wrong way to direct IRA.
In case of test1, pseudo 42 is in two insns involving hard register
24. Therefore its cost is decreased in ira-costs.c. After that it
is increased on the same value because the pseudo intersects one call
and the cost of ld/st (for save/restore) is the same as for moving
its value into a general register. Because r24 is the first in the
hard register allocation order, IRA chooses r24.
So making ld/st a bit more costly than hard register moving would
solve the problem. Unfortunately, it does not happens because the
two move insns involving p42 and hard register 24 are taken into
account twice (once in ira-costs.c and another one
ira-conflicts.c:process_regs_for copy).
The following patch would solve the problem. I'll submit it when gcc
is in stage 1. The patch looks harmless but changes in ira-costs.c
frequently trigger reload failures. Therefore the patch needs
thorough testing and stage1 is best time to do it.
Thanks for that patch. With that patch, slightly increasing memory
costs (2 instead of 4 without the patch) is sufficient to get good code.
Isn't reload supposed to word in all situations or for different cost
setups? Sounds as if that is working around problems in reload.
Reload exists since day 1 of GCC (actually its idea came from a portable
Pastel compiler of Livermoore Laboratory). It came a long way of big
changes as it is the most target dependent code in machine-independent
part of compiler.
Now reload is too hard to understand (the most complicated code in GCC
imho) with a lot of inconsistent data on the side of RTL. It is a
permanent source of latent bugs and frequently any change (to fix a bug)
results in occurrence of new bugs. Sometimes changes in RA, combiner,
and insn scheduler trigger latent bugs in reload.
There were several tries to rewrite it (all of them failed) and make it
more consistent (the last successful one was Bernd Schmidt's more 10
years ago). In some way reload is doing a good work (especially with
compiler time point of view) but it tries to do a lot of tasks at the
same time (code selection, transformations to satisfy insn and address
constraints, a lot of optimizations of the transformations, register
elimination, reusage of values in hard registers through so called
inheritance in bb scope, register rematerialization, stack slots reusage
etc) and that makes it too complicated.
Thanks for pointing the problem. It helped to find some cost
calculation pitfall which was probably introduced by an IRA change
in ira-costs.c inconsistent with the code in ira-conflicts.c.
Maybe you like to take care of
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01443.html
in stage 1? It takes into account LOCAL_REGNO in
ira-color.c:assign_hard_reg.
Thanks for the patch. It looks ok to me. I approve the patch for the
stage 1.
