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

[Jie He via llvm-dev]

Hi Philip

Thanks for your response.

Yes, previously, I also thought there is one pass which could change the
predicate from ">=" to "<", like some gvn passes did, update "-" to "+".
but I can't find it.

I tried to use -O3 to build the code, the target IR file shows all
conditions are uniformed to "EQ". and then took the IRCE pass, no
optimization occurs.
I didn't check the code why it didn't happen, because I know there is
another thing which causes IRCE doesn't work when trip count
comparison uses "EQ/NE", but it's irrelevant to this thread.

B.R
Jie He

On Fri, 5 Feb 2021 at 09:05, Philip Reames <listmail at philipreames.com>
wrote:

> )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 listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

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