Why LLVM does not remember an integer range when the variable has been constrained by an if statement? - clang

Question

There is a problem that has become quite popular these last days regarding the LLVM/GCC inability to optimize a trivial loop when the range is quite obvious.
Godbolt for all the examples below: https://godbolt.org/z/b3PzrsE5e
The code below will not optimize and the generated assembly will produce a loop.
uint64_t sum1( uint64_t num ) {
uint64_t sum = 0;
for ( uint64_t j=0; j<=num; ++j ) {
sum += 1;
}
return sum;
}
produces
sum1(unsigned long): # #sum1(unsigned long)
xorl %eax, %eax
.LBB0_1: # =>This Inner Loop Header: Depth=1
addq $1, %rax
cmpq %rdi, %rax
jbe .LBB0_1
retq
However if one adds a limiter to the range of the variable, like an AND mask, the loop is able to optimize. You can also easily make it optimize if you change the condition j<=num to j<num+1.
uint64_t sum2( uint64_t num ) {
num &= 0xFFFFFFFFULL;
uint64_t sum = 0;
for ( uint64_t j=0; j<=num; ++j ) {
sum += 1;
}
return sum;
}
produces
sum2(unsigned long): # #sum2(unsigned long)
movl %edi, %eax
addq $1, %rax
retq
while curbing the range with an if statement does not have any effect
uint64_t sum3( uint64_t num ) {
uint64_t sum = 0;
if ( num <= 0xFF ) {
for ( uint64_t j=0; j<=num; ++j ) {
sum += 1;
}
}
return sum;
}
Produces assembly code again with a loop.
sum3(unsigned long): # #sum3(unsigned long)
xorl %eax, %eax
cmpq $255, %rdi
ja .LBB3_2
.LBB3_1: # =>This Inner Loop Header: Depth=1
addq $1, %rax
cmpq %rdi, %rax
jbe .LBB3_1
.LBB3_2:
retq
For that sake, even __builtin_assume( num < 0x100ULL ) has no effect on the result.
I have looked into the LLVM code and traced this to the failed statement at
// lib/Transforms/Scalar/IndVarSimplify.cpp:1430
const SCEV *MaxExitCount = SE->getSymbolicMaxBackedgeTakenCount(L);
if (isa<SCEVCouldNotCompute>(MaxExitCount)) {
printf( "Could not compute\n");
return false;
}
...
which then ends up in
// lib/Analysis/ScalarEvolution.cpp:7253
const SCEV *ScalarEvolution::getExitCount(const Loop *L,
const BasicBlock *ExitingBlock,
ExitCountKind Kind) {
switch (Kind) {
case Exact:
case SymbolicMaximum:
return getBackedgeTakenInfo(L).getExact(ExitingBlock, this);
case ConstantMaximum:
return getBackedgeTakenInfo(L).getConstantMax(ExitingBlock, this);
};
llvm_unreachable("Invalid ExitCountKind!");
}
What I don't understand is why the boundary cannot be inferred if the if statement makes it clear? Is this a feature that could be implemented? Am I in the right track?