Trip notes from Israel

[Andrei Alexandrescu via Digitalmars-d-announce]

On 05/23/2017 09:42 AM, Stefan Koch wrote:
> On Tuesday, 23 May 2017 at 13:27:42 UTC, Andrei Alexandrescu wrote:
>> On 5/22/17 4:51 PM, Johan Engelen wrote:
>>> On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:
>>>> [...]
>>>
>>> A fun read!
>>>
>>> "(Late at night, I double checked. Mozilla’s CheckedInt is just as 
>>> bad as I remembered. They do a division to test for multiplication 
>>> overflow. Come on, put a line of assembler in there! Portability is 
>>> worth a price, just not any price.)"
>>>
>>> Shocked: do you use assembly in Checked and cripple the optimizer?!?!
>>> Luckily, no. But LDC and GDC do create the `seto` instruction I think 
>>> you were hinting at:
>>> https://godbolt.org/g/0jUhgs
>>>
>>> (LDC doesn't do as good as it could, 
>>> https://github.com/ldc-developers/ldc/issues/2131)
>>
>> Thanks! Yes, seto is what I thought of - one way or another, it gets 
>> down to using a bit of machine-specific code to get there. I'll note 
>> that dmd does not generate seto (why?): https://goo.gl/nRjNMy. -- Andrei
> 
> it does this
> overflow_flag = 0
> op
> if (overflowed)
> {
>    overflow_flag = 1;
> }

Where did you see this pattern? Couldn't find it anywhere in 
core.checkedint. And how is "overflowed" tested?

> this can in some circumstances be faster then using seto!
> If the inliner does a good enough job :)

The code in core.checkedint is conservative:

pragma(inline, true)
ulong mulu(ulong x, ulong y, ref bool overflow)
{
     ulong r = x * y;
     if (x && (r / x) != y)
         overflow = true;
     return r;
}

The compiler is supposed to detect the pattern and generate optimal code.


Andrei