Kenneth Zadeck <zad...@naturalbridge.com> writes: > Richard, > > 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 the two. So yeah, applying it on a function-by-function basis is probably better. Does anyone else have any thoughts before I make that change? Richard
