search for: getspillweight

...take over this effort or should I poke more at it? > > Since you've already started, it's easier if you poke more at it. Thanks. I've got a whole bunch of other things to go through. OK, will do. Jakob any comments on the patch? The only interesting part is in LiveIntervals::getSpillWeight. Do we have to scale the values somehow there? - Ben

...I poke more at it? >> >> Since you've already started, it's easier if you poke more at it. Thanks. I've got a whole bunch of other things to go through. > > OK, will do. > > > Jakob any comments on the patch? The only interesting part is in LiveIntervals::getSpillWeight. Do we have to scale the values somehow there? Yes, BlockFrequency::getFrequency() is poorly named, it returns a fixpoint number. I think you should scale it to be relative to the entry block frequency. +LiveIntervals::getSpillWeight(bool isDef, bool isUse, BlockFrequency freq) { + return (isDef...

...gt; >>> Since you've already started, it's easier if you poke more at it. Thanks. I've got a whole bunch of other things to go through. >> >> OK, will do. >> >> >> Jakob any comments on the patch? The only interesting part is in LiveIntervals::getSpillWeight. Do we have to scale the values somehow there? > > Yes, BlockFrequency::getFrequency() is poorly named, it returns a fixpoint number. I think you should scale it to be relative to the entry block frequency. > > +LiveIntervals::getSpillWeight(bool isDef, bool isUse, BlockFrequency freq...

...of the basic block where the spill is inserted. My goal is to analyse what effect scheduling changes have on the sum of this weighted spill cost in some benchmarks. I've experimented doing this directly before a spill is inserted in InlineSpiller.cpp using MBFI.getBlockFreq() and LiveIntervals::getSpillWeight. My question is why are these functions sometimes indicating that the frequency of a block, or the weight of a spill is 0? A frequency of 0 doesn't make sense to me. Thanks, Austin Kerbow

On Jun 17, 2013, at 10:48 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > [Splitting this out from the original thread to reduce noise in it] > > > On 17.06.2013, at 18:43, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> +LiveIntervals::getSpillWeight(bool isDef, bool isUse, BlockFrequency freq) { >> + return (isDef + isUse) * freq.getFrequency(); >> } >> >> This computation can overflow. > > Yep, I went down the easy route and converted it to floating point arithmetic. Is that OK here? Yes, that should be fine....

...of the basic block where the spill is inserted. My goal is to analyse what effect scheduling changes have on the sum of this weighted spill cost in some benchmarks. I've experimented doing this directly before a spill is inserted in InlineSpiller.cpp using MBFI.getBlockFreq() and LiveIntervals::getSpillWeight. My question is why are these functions sometimes indicating that the frequency of a block, or the weight of a spill is 0? A frequency of 0 doesn't make sense to me. I don’t know how PGO is implemented in that respect so take it with a grain of salt, but if you’re using PGO, I am guessing that...

On 2013-06-15 16:39 , Benjamin Kramer wrote: > Do you want to take over this effort or should I poke more at it? Since you've already started, it's easier if you poke more at it. Thanks. I've got a whole bunch of other things to go through. Diego.

On 13.06.2013, at 19:12, Diego Novillo <dnovillo at google.com> wrote: > On 2013-06-12 18:15 , Chandler Carruth wrote: >> >> On Wed, Jun 12, 2013 at 3:10 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> It predates the block frequency interface. It just needs to be hooked up, patches welcome. It would also be nice to remove the floating point computations