[llvm-commits] [llvm] r162799 - in /llvm/trunk: include/llvm/Analysis/Passes.h include/llvm/Analysis/ProfileDataLoader.h include/llvm/InitializePasses.h include/llvm/LinkAllPasses.h lib/Analysis/Analysis.cpp lib/Analysis/CMakeLists.txt lib/Analysis/ProfileDataLoader.cpp lib/Analysis/ProfileDataLoaderPass.cpp lib/Analysis/ProfileInfo.cpp test/Analysis/Profiling/load-branch-weights-ifs.ll test/Analysis/Profiling/load-branch-weights-loops.ll test/Analysis/Profiling/load-branch-weights-switches.ll

Bill Wendling wendling at apple.com
Thu Aug 30 22:21:48 PDT 2012


On Aug 30, 2012, at 4:23 PM, Alastair Murray <alastairmurray42 at gmail.com> wrote:

> Hi Bill,
> 
> On 30/08/12 21:24, Bill Wendling wrote:
>> The patch looks fine. Thank you for doing it! Let me know if you don't have commit access and I can apply it for you.
> 
> I do not have commit access, so if you could please apply it it would be appreciated!
> 
Okay. Done in r162979. Thanks!

>> If the namespace issue is messing things up, then you can leave it. It was a minor issue. I'm still not 100% convinced about the weight code. I doubt that you're gaining much by expanding to uint64_t and then back to unsigned. If anything, you should probably just use uint64_t directly in the whole function instead of casting (which, gross):
>> 
>> static uint64_t AddCounts(uint64_t A, uint64_t B) {
>>   // ...
>> }
>> 
>> Would this address your concerns?
> 
> Yes, I could do this.  Reading between the lines, however, I could just not saturate on overflow but leave it unhandled?  Is that preferable?
> 
If you could give an example of what you're trying to do, that might be better. We may not be talking about the same thing. What does the math look like that you're trying to handle by going to uint64_t?

-bw

> I'll try and get the MemoryBuffer patch written tomorrow.
> 
> Regards,
> Alastair.




More information about the llvm-commits mailing list