[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

[Jakob Stoklund Olesen]

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