search for: getentryfrequency

...>> >> 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 = BlockFrequency::getEntryFrequency(); + return (isDef + isUse) * (freq.getFrequency() / EntryFreq); Nitpick: The float division can be constant folded and turned into a multiplication: const float Scale = 1.0f / getEntryFrequency(); return (isDef + isUse) * (freq.getFrequency() * Scale); I wouldn’t trust the compiler to do t...

[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: > > On Jun 17, 2013, at 7:03 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > >> >> On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: >> >>> On 2013-06-15 16:39 ,

...ve a good start on that already with the branch probability metadata. The missing piece is adding per-function metadata to record the execution counts. We had planned to add that along with the branch probabilities but haven't gotten it done yet. You can see the lack of it in BlockFrequency::getEntryFrequency(), which just returns a constant value. We will want that to allow comparing profile data across different functions, which you can't easily get from the branch probabilities alone. I don't think anyone has yet come up with a specific proposal for that. As long as we agree on the canoni...

On 2013-06-15 14:18 , Evan Cheng wrote: > Apple folks are also gearing up to push on the PGO front. We are > primarily interested in using instrumentation, rather than sampling, > to collect profile info. However, I suspect the way profile ended up > being used in the various optimization and codegen passes would be > largely similar. > Excellent! We are initially