Challenge: Make a data type for holding one of 8 directions allowing increment and overflow

[Basile B.]

On Friday, 15 March 2024 at 00:00:01 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
>
> On 15/03/2024 12:47 PM, Basile B. wrote:
>> On Thursday, 14 March 2024 at 23:39:33 UTC, Liam McGillivray 
>> wrote:
>>> On Thursday, 14 March 2024 at 01:58:46 UTC, Richard (Rikki) 
>>> Andrew Cattermole wrote:
>>>> [...]
>>>
>>> I tried to rework the functions to use bitwise operations, 
>>> but it was difficult to figure out the correct logic. I 
>>> decided that it's not worth the hassle, so I just changed the 
>>> value storage from `bool[3]` to `ubyte`. Now it works much 
>>> more like your version.
>>> https://github.com/LiamM32/Open_Emblem/blob/c2014ab3f77e89c0cedcd6dbf7f8362ebfac33a9/source/common.d
>>>
>>> I did a little reading, so now I understand what it means 
>>> when you have `&= 7`. But I want to ask, is this faster than 
>>> `%= 8`? If not, I would like to change it to the latter for 
>>> readability.
>> 
>> `%=8` will be codegened using slower intructions w/o optimz 
>> enabled but with `&=7` you directly get the right instruction, 
>> which does not involves integer division. See 
>> https://godbolt.org/z/74vbba5aG
>
> Yes, it'll depend upon how smart the compiler is at optimizing 
> and it may not occur in non-optimizing builds.

Indeed GDC (so very likely GCC too, or whatever language uses it 
as backend...) does it without optimz 
(https://godbolt.org/z/Ke7c54Gqj).

That's not very surprising. If you look at LLVM bug tracker, for 
the tag "missed optimisations", in the report body you'll see a 
lot of "GDC does that but we dont", even if here it's a bit 
different, as optimz are not enabled.