llvm dev - Feb 2021 - Why IRCE wouldn't deal with the range check which has a predicate "uge"?

Hi

Recently, I tried to use llvm to optimize my code generated by a
managed VM. this VM will instrument many range check codes before
memory access operations.
I found the optimization IRCE wouldn't work when the range check with
the predicate "uge". I wrote the following c/c++ code to simulate my
code, where len is the max buf length:

void testIRCE(unsigned int * buf, unsigned int len, unsigned int
iteration_count) {
    if (iteration_count > 0) {
        unsigned int i = 0;
        do {
            if (i >= len) { // range check
                printf("overflow\n");
                return;
            }

            buf[i] = i;

            i ++;

        } while (i < iteration_count);
    }
}

the above code wouldn't be optimised as expected into 2 loops
(iteration range splitting). I checked the llvm code, found in the
function InductiveRangeCheck::parseRangeCheckICmp(), it wouldn't deal
with uge cases, I'm not sure if it is intentional.

but I tried to modify the llvm IR code by replacing the uge to ult,
and interchanging the operands of next branch instruction. the
optimization IRCE works as expected.

my test command is below:
first, get a clean llvm IR file.
./clang++ -O3 -Xclang -disable-llvm-passes  ~/testRCE.cpp  -emit-llvm
-S -o ~/testRCE.TBBA.ll

second, optimize it with other loop optimization.
./opt -gvn -simplifycfg -loop-simplify -loop-predication -licm -dce
-mem2reg -dce -jump-threading -lcssa -simplifycfg -loop-simplify  -dce
-stats -debug-pass=Executions ~/testRCE.TBBA.ll -S -o
~/testRCE.mem2reg.ll

finally, take IRCE.

./opt -irce-skip-profitability-checks -irce -dce -S ~/testRCE.mem2reg.ll -o
~/testRCE.irce.ll--


Best Regards
He Jie 何杰
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210204/f1401bfb/attachment.html>

)Quick response, may be off base as I'm taking a guess based on a quick 
read through.)

IRCE - like many llvm passes - assumes IR has been canonicalized by 
other passes.  If you run your IR through -O3 and then IRCE, do you get 
what you expect?

Philip

On 2/4/21 12:43 AM, Jie He via llvm-dev wrote:
> Hi
> Recently, I tried to use llvm to optimize my code generated by a managed
VM. this VM will instrument many range check codes before memory access
operations.
> I found the optimization IRCE wouldn't work when the range check with
the predicate "uge". I wrote the following c/c++ code to simulate my
code, where len is the max buf length:
>
> void testIRCE(unsigned int * buf, unsigned int len, unsigned int
iteration_count) {
>      if (iteration_count > 0) {
>          unsigned int i = 0;
>          do {
>              if (i >= len) { // range check
>                  printf("overflow\n");
>                  return;
>              }
>
>              buf[i] = i;
>
>              i ++;
>
>          } while (i < iteration_count);
>      }
> }
>
> the above code wouldn't be optimised as expected into 2 loops
(iteration range splitting). I checked the llvm code, found in the function
InductiveRangeCheck::parseRangeCheckICmp(), it wouldn't deal with uge cases,
I'm not sure if it is intentional.
>
> but I tried to modify the llvm IR code by replacing the uge to ult, and
interchanging the operands of next branch instruction. the optimization IRCE
works as expected.
>
> my test command is below:
> first, get a clean llvm IR file.
> ./clang++ -O3 -Xclang -disable-llvm-passes  ~/testRCE.cpp  -emit-llvm -S -o
~/testRCE.TBBA.ll
>
> second, optimize it with other loop optimization.
> ./opt -gvn -simplifycfg -loop-simplify -loop-predication -licm -dce
-mem2reg -dce -jump-threading -lcssa -simplifycfg -loop-simplify  -dce -stats
-debug-pass=Executions ~/testRCE.TBBA.ll -S -o ~/testRCE.mem2reg.ll
>
> finally, take IRCE.
> ./opt -irce-skip-profitability-checks -irce -dce -S 
> ~/testRCE.mem2reg.ll -o ~/testRCE.irce.ll--
>
>
> Best Regards
> He Jie 何杰
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210204/929cf66c/attachment.html>