この回答を書いたとき、私は一般的に<vs. <=に関するタイトルの質問だけを見ていました。定数a < 901vs.の具体的な例ではありませんでしたa <= 900。多くのコンパイラは、<との間で変換することにより、常に定数の大きさを縮小します<=。たとえば、x86の即値オペランドは-128..127の1バイトエンコーディングが短いためです。
ARM、特にAArch64の場合、即時としてエンコードできるかどうかは、狭いフィールドを単語の任意の位置に回転できるかどうかにかかっています。したがってcmp w0, #0x00f000、エンコード可能ですが、エンコードcmp w0, #0x00effffできない場合があります。したがって、比較とコンパイル時の定数のmake-it-smallerルールは、AArch64に常に適用されるわけではありません。
<対<=一般的に、ランタイム変数条件を含む
ほとんどのマシンのアセンブリ言語では、の比較<=はの比較と同じコストです。<ます。これは、分岐する場合、ブール化して0/1整数を作成する場合、または分岐なしの選択操作（x86 CMOVなど）の述語として使用する場合に適用されます。他の回答は、質問のこの部分のみを扱っています。
しかし、この質問は、オプティマイザへの入力であるC ++演算子についてです。 通常、どちらも同等に効率的です。コンパイラーは常にasmで実装する比較を変換できるため、この本のアドバイスはまったく偽物に聞こえます。しかし、少なくとも1つの例外があり、<=、コンパイラを最適化できないものを誤って作成する可能性があります。
ループ条件として、コンパイラがループが無限ではないことを証明できないようにする場合、<=と質的に異なる場合があり<ます。 これにより、大きな違いが生じ、自動ベクトル化が無効になります。
符号なしオーバーフローは、符号付きオーバーフロー（UB）とは異なり、base-2ラップアラウンドとして明確に定義されています。署名されたループカウンターは、通常、署名されたオーバーフローUBに基づいて最適化されるコンパイラーが発生しない場合、++i <= sizeこれから安全です。常に最終的にfalseになります。（すべてのCプログラマが未定義の動作について知っておくべきこと）
void foo(unsigned size) {
unsigned upper_bound = size - 1; // or any calculation that could produce UINT_MAX
for(unsigned i=0 ; i <= upper_bound ; i++)
...
コンパイラーは、未定義の動作につながるものを除いて、可能なすべての入力値に対してC ++ソースの（定義された、法的に観察可能な）動作を維持する方法でのみ最適化できます。
（単純なものでi <= sizeも問題が発生しますが、上限の計算は、気にしていないがコンパイラーが考慮しなければならない入力の無限ループの可能性を誤って導入するより現実的な例だと思いました。）
この場合、size=0はにつながりupper_bound=UINT_MAX、i <= UINT_MAX常にtrueです。したがって、このループはに対して無限でありsize=0、プログラマとしてのあなたがおそらくsize = 0を渡すつもりがない場合でも、コンパイラはそれを尊重する必要があります。コンパイラーがこの関数を呼び出し側にインライン化できる場合、size = 0が不可能であることを証明できれば、すばらしいですが、のように最適化できi < sizeます。
asm like if(!size) skip the loop; do{...}while(--size);は、for( i<size )ループ内で実際の値がi必要ない場合に、ループを最適化するための通常効率的な方法の1つです（なぜ、ループは常に「do ... while」スタイル（テールジャンプ）にコンパイルされるのですか？）。
しかし、これは{}間無限にすることはできません。で入力した場合size==0、2 ^ n回の反復が行われます。（forループ C ですべての符号なし整数を反復すると、0を含むすべての符号なし整数でループを表現できますが、asmのようにキャリーフラグがないと簡単ではありません。）
ループカウンターのラップアラウンドが可能である場合、最近のコンパイラーは、しばしば「あきらめ」、ほとんど積極的に最適化しません。
例：1からnまでの整数の合計
符号なしi <= nを使用sum(1 .. n)すると、ガウスのn * (n+1) / 2式に基づいて閉形式でループを最適化するclangのイディオム認識が無効になります。
unsigned sum_1_to_n_finite(unsigned n) {
unsigned total = 0;
for (unsigned i = 0 ; i < n+1 ; ++i)
total += i;
return total;
}
Godboltコンパイラエクスプローラーのclang7.0およびgcc8.2からのx86-64 asm
# clang7.0 -O3 closed-form
cmp edi, -1 # n passed in EDI: x86-64 System V calling convention
je .LBB1_1 # if (n == UINT_MAX) return 0; // C++ loop runs 0 times
# else fall through into the closed-form calc
mov ecx, edi # zero-extend n into RCX
lea eax, [rdi - 1] # n-1
imul rax, rcx # n * (n-1) # 64-bit
shr rax # n * (n-1) / 2
add eax, edi # n + (stuff / 2) = n * (n+1) / 2 # truncated to 32-bit
ret # computed without possible overflow of the product before right shifting
.LBB1_1:
xor eax, eax
ret
しかし、単純なバージョンの場合、clangからばかげたループを取得するだけです。
unsigned sum_1_to_n_naive(unsigned n) {
unsigned total = 0;
for (unsigned i = 0 ; i<=n ; ++i)
total += i;
return total;
}
# clang7.0 -O3
sum_1_to_n(unsigned int):
xor ecx, ecx # i = 0
xor eax, eax # retval = 0
.LBB0_1: # do {
add eax, ecx # retval += i
add ecx, 1 # ++1
cmp ecx, edi
jbe .LBB0_1 # } while( i<n );
ret
GCCはどちらの方法でも閉形式を使用しないため、ループ条件の選択が実際に害を及ぼすことはありません。SIMD整数加算で自動ベクトル化しi、XMMレジスタの要素で4つの値を並列に実行します。
# "naive" inner loop
.L3:
add eax, 1 # do {
paddd xmm0, xmm1 # vect_total_4.6, vect_vec_iv_.5
paddd xmm1, xmm2 # vect_vec_iv_.5, tmp114
cmp edx, eax # bnd.1, ivtmp.14 # bound and induction-variable tmp, I think.
ja .L3 #, # }while( n > i )
"finite" inner loop
# before the loop:
# xmm0 = 0 = totals
# xmm1 = {0,1,2,3} = i
# xmm2 = set1_epi32(4)
.L13: # do {
add eax, 1 # i++
paddd xmm0, xmm1 # total[0..3] += i[0..3]
paddd xmm1, xmm2 # i[0..3] += 4
cmp eax, edx
jne .L13 # }while( i != upper_limit );
then horizontal sum xmm0
and peeled cleanup for the last n%3 iterations, or something.
また、非常に小さいn、または無限ループの場合に使用すると思われる単純なスカラーループもあります。
ところで、これらのループはどちらも、ループオーバーヘッドの命令（およびSandybridgeファミリCPUのuop）を無駄にします。 sub eax,1/ cmp / jccのjnz代わりにadd eax,1/がより効率的です。2ではなく1 uop（sub / jccまたはcmp / jccのマクロ融合後）。両方のループの後のコードは無条件にEAXを書き込むため、ループカウンターの最終値を使用していません。