On 03/02/2016 10:53 PM, Vladimir Makarov wrote:
2. update_costs_from_allocno records a cost update not just for the
initial allocno, but for each of the visited ones. I can sort of see
an argument for doing that (let's say if you assign an allocno in the
middle of a copy chain you'd want the tail end of the chain to be
reset), but in practice I don't think the present algorithm can work
at all. In the case of an allocno in the middle of a copy chain the
restore would progress in both directions, and in any case it looks
like this approach can end up double-counting things when restoring
costs.
It is just a heuristic. Richard Sandiford proposed this update
approach. Before it we had only updates of allocnos directly connected
to allocno in question. Richard's approach helped to improve code in
some cases. If something works better we should use. The bechmarking
is the best criterium.
Ccing Richard in case he has comments.
The patch is ok for me. But I'd wait for GCC7. People are sensitive to
their code performance degradation. Even in most cases the patch
improves performance, in some case it can worsen code and people might
fill new PRs after such change.
Bernd, thanks for working on it and providing a fresh view of the code.
For me especially valuable when people benchmark their patches.
Sometimes I have to do it by myself.
Ok, I'll wait. I did not actually run any benchmarks either, but I
looked at generated code for a large number of examples. Based on that I
suspect the effect would be too small to detect with benchmark runs.
Bernd
