A Friendly Challenge for D

[Jabari Zakiya]

On Tuesday, 16 October 2018 at 20:38:24 UTC, welkam wrote:
> On Tuesday, 16 October 2018 at 17:57:23 UTC, Jabari Zakiya 
> wrote:
>> This is the exact same behavior I found with the Nim compiler 
>> too.
>
> Well Nim compiler is more like translator. It translates Nim 
> code to c or c++. Since gcc was responsible for optimizations 
> and instruction selection it would be more correct to say that 
> gcc behavior was same as llvm.
>
>
>> How many other unknown gotchas are in the compilers? :-(
>
> the number of inlining shall be 3
> https://www.youtube.com/watch?v=s4wnuiCwTGU

Yes, it finally is the compiler doing it, and Clang does the same 
thing.
And they could be modded to catch semantics like this and produce 
faster code.

My guess is the difference in code execution times based on the 
ALU operation pipeline.

seg[k] = seg[k] | 1

can be done "inplace" in the pipeline, where the lsb can to be 
changed in mem, whereas

seg[k] = 1

may require a separate constant|value creation and memory write, 
and bypass the ALU.

I used to know most of these tricks back in the Pentium days, but 
I haven't had a need to keep up with Intel Ixx core chips 
machine|compiler level instruction optimizations.