[llvm-commits] [llvm] r132613 - in /llvm/trunk: include/llvm/Analysis/BranchProbabilityInfo.h include/llvm/InitializePasses.h lib/Analysis/Analysis.cpp lib/Analysis/BranchProbabilityInfo.cpp lib/Analysis/CMakeLists.txt

[Andrew Trick]

On Jun 4, 2011, at 9:53 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

> 
> On Jun 4, 2011, at 1:50 AM, Frits van Bommel wrote:
> 
>> On 4 June 2011 10:19, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>>> On Jun 4, 2011, at 12:56 AM, Frits van Bommel wrote:
>>>> Shouldn't you use 'uint32_t' instead of 'unsigned (int)' throughout
>>>> (and UINT32_MAX instead of UINT_MAX, etc.)?
>>> 
>>> LLVM assumes that unsigned is 32 bits in *many* places. It won't work with
>>> any other int size.
>> 
>> Do they assume it's 32 bits, or that it's *at least* 32 bits?
> 
> You can grep '~0' on the sources to get an idea, but I am sure most places would work with a larger int.
> 
>> Note
>> that this code essentially assumes it's *exactly* 32 bits because its
>> results depend on the exact value of UINT_MAX.
> 
> Sure, let's use UINT32_MAX for the exact value.
> 
>> But even if what you say is true, I don't consider that to be a good
>> excuse to contribute to the problem.
> 
> Which problem? 36-bit preparedness?
> 
>> And many places in LLVM use
>> (u)int32_t, too.
>> 
>> If nothing else, uint32_t is more self-documenting.
> 
> If a C implementation decides to take on all the portability issues that come from having a 64-bit int, it has to be because 32-bit arithmetic performance is horrible. The uint32_t type makes sense when you need the compact size, or when you depend on modulo 2^32 arithmetic.
> 
> /jakob
> 
Then what do we cast to for overflow checking?

Andy