Kenneth Zadeck <zad...@naturalbridge.com> writes:
> thanks, for doing the changes. In particular, i did not really
> understand how the target stuff was supposed to work.
> I have one issue with the changes that you made.
> I had actually decided that the speed/size decision was not relevant to
> this patch. The problem is that since this is a global optimization
> which propagates the info across the entire web of moves, you really
> want/need to use the same cost metric everywhere. (of course, making
> the speed/size decision on the global optimization level would be fine;
> my issue is with the choice being at the bb level.) So now you are
> going to have some moves in a web saying yes while others saying no.
> The ones that say no will dominate. It is unlikely you will get what
> you want (the important nodes really running fast) out of this, assuming
> you have a target where the decision could go either way.
Yeah, I suppose that's true. The problem is that both ways are wrong really.
If we just use the function-level speed setting, there'll be times where
a cold-only web will be optimised as hot. But as you say, if we apply
the bb-level setting, cold blocks can hold back the hot blocks.
And I don't particularly relish the idea of trying to joust between
So yeah, applying it on a function-by-function basis is probably better.
Does anyone else have any thoughts before I make that change?