Not sure this is worth it..

If you're not sure, test it with SPRT[0, 5] (as indicated in the guidelines, btw)

@vondele I would be surprised if speed up is confirmed, cmh, fmh, and fmh2 are loop invariant values so they should be optimized in the compiler or even in the CPU's branch prediction.

OTH I don't see any readability improvement here.

@mcostalba the hoisting of the loop invariant loads is happening, but the loop unswitching (for three conditionals) is not... at least with my setup. Would be good if speedup could be measured independently.

I agree that it isn't a readability improvement, just an (eventual) speedup.

I confirm speed on my main PC: build with GCC 6.3.0 Profile Build, lto under Windows
Version1 is current Master
Version2 is this patch.
each 100 runs of bench 16 1 15 => 0.93% speedup

Build Tester: 1.4.6.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
AMD FX(tm)-9590 Eight-Core Processor
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench 16 1 15 default depth
Tests per Build: 100
ANOVA: n/a

            Engine# (NPS)                     Speedup     Sp     Conf. 95%    S.S.

2 (1.705.211,1 ) ---> 1 (1.689.433,4 ) ---> 0,934% 23.800,6 Yes No

slower here , macOS, gcc4.8, PGO build, concurrent runs

bench 16 1 24
head
Total time (ms) : 266287
Nodes searched  : 466008793
Nodes/second    : 1750024

base
Total time (ms) : 268072
Nodes searched  : 466008793
Nodes/second    : 1738371

#1021 is the better approach and renders this patch unnecessary. Closing.