search for: getfrequ

...anks. 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 + isUse) * freq.getFrequency(); > } > > This computa...

...ier 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 + isUse) * freq.getFrequency(); } This computation can overflow. @@ -178,9...

On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: > 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. OK, will do. Jakob any comments on the

...> [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. +LiveIntervals::getSpillWeight(bool isDef, bool isUse, BlockFrequency freq) { + float EntryFreq...

...;order" parameter. How are paths ordered? By number? Why does the returned order of paths matter? > /* > * Returns the execution count for a path. > */ > unsigned long Path::getCount() > /* > * Returns the execution frequency for a path. > */ > float Path::getFrequency() The naming is a bit confusing here. "getCount" makes sense, but "getFrequency" could mean a few different things. My assumption is that it means the % of times this path was taken vs. the number of times the Function was invoked. It could also mean the % of times th...

Hello, I am planning on contributing path profiling to LLVM by the end of August. I have written a document of what the interface to the path profiles would look like at that time. If someone has any amendments, I can incorporate them. http://www.cs.ualberta.ca/~pejic/PathProfiling.html Slobodan Pejic

...ecution, and will not require the majority of the path profile. > >> /* >> * Returns the execution count for a path. >> */ >> unsigned long Path::getCount() > >> /* >> * Returns the execution frequency for a path. >> */ >> float Path::getFrequency() > > The naming is a bit confusing here. "getCount" makes sense, but > "getFrequency" could mean a few different things. My assumption is that it > means the % of times this path was taken vs. the number of times the Function > was invoked. It could al...