Re: [RFC][BZ #17943] Use long for int_fast8_t

[Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>]

On 11/02/15 18:26, Richard Earnshaw wrote:
> On 11/02/15 13:34, OndÅej BÃlka wrote:
>> On Mon, Feb 09, 2015 at 01:13:24PM -0500, Rich Felker wrote:
>>> On Sun, Feb 08, 2015 at 12:04:26PM +0100, OndÅej BÃlka wrote:
>>>> Hi, as in bugzilla entry what is rationale of using char as int_fast8_t?
>>>>
>>>> It is definitely slower with division, following code is 25% slower on
>>>> haswell with char than when you use long.
>>>
>>> This claim is nonsense. It's a compiler bug. If the 8-bit divide
>>> instruction is slow, then the compiler should use 32-bit or 64-bit
>>> divide instructions to divide 8-bit types. (Note: there's actually no
>>> such thing as a division of 8-byte types; formally, they're promoted
>>> to int, so it's the compiler being stupid if it generates a slow 8-bit
>>> divide instruction for operands that are formally int!) There's no
>>> reason to use a different type for the _storage_.
>>>
>> That is also nonsense, you cannot get same speed as 32bit instruction
>> without having 8bit instruction with same performance.
>>
>> Compiler must add extra truncation instructions to get correct result
>> which slows it down, otherwise it gets wrong result for cases like (128+128)%3
>>
> 
> Only if the intermediate result (128+128) is assigned directly to a
> variable with less precision than int. 

Or, of course, if an explicit cast is applied to the intermediate result.


> Otherwise the whole expression
> is calculated with int precision.
> 
> R.
>