[llvm-commits] [llvm] r80907 - /llvm/trunk/lib/Analysis/ProfileInfoLoaderPass.cpp

[Dale Johannesen]

On Sep 3, 2009, at 1:32 AMPDT, Andreas Neustifter wrote:

> Hi,
>
> Daniel Dunbar wrote:
>> On Thu, Sep 3, 2009 at 12:53 AM, Andreas Neustifter<astifter-llvm at gmx.at 
>> > wrote:
>>> Hi,
>>>
>>> thank you very much for investigating this!
>>>
>>> Daniel Dunbar wrote:
>>>> -  if (weight != (unsigned)MissingValue) {
>>>> +  if (weight != ~0U) {
>>> Since allmost all my other development takes place on platforms  
>>> that do
>>> not even support floating point my float-typecasting knowledge is  
>>> a bit
>>> rusty.
>>>
>>> If you have time: can you explain why this is necessary and why  
>>> the cast
>>> from double to unsigned does not work? (At least not on all  
>>> platforms...)
>>
>> I didn't know this off the top of my head either, but the relevant
>> language for C99 (I presume C++ is similar is):
>> --
>> 6.3.1.4p1: When a finite value of real floating type is converted to
>> an integer type other than _Bool, the fractional part is discarded
>> (i.e., the value is truncated toward zero). If the value of the
>> integral part cannot be represented by the integer type, the behavior
>> is undefined.
>> --
>
> Thanks, so maybe we should convert all the counters to (signed)  
> int64_t
> to clean up this problem and get larger counters...

There is another unfortunate but solid reason for avoiding compile- 
time floating point arithmetic:  when the host uses x87, the poor  
design of that architecture can result in differing results depending  
on whether the compiler is built optimized or not.   You can use a   
multiplier to represent fractional values as integers, with range  
limitations; see the various uses of REG_BR_PROB_BASE in the gcc  
source.   This is ugly, and best avoided if you can do what you want  
without having values that are logically fractions.