Karl Rehm via llvm-dev
2020-Feb-03 20:50 UTC
[llvm-dev] Questions about jump threading optimization and what we can do
Hm. I assumed that JumpThreading would be the primary factor in optimizing code like this. Guess not. I'll need to look into SimplifyCFG to see what prevents it from doing the same thing to the other loop: https://godbolt.org/z/F6NjdG On Mon, Feb 3, 2020 at 3:09 PM Michael Kruse <llvmdev at meinersbur.de> wrote:> I assumed the LLVM-IR behind the godbolt link represented the C code > you used before. > > SimplifyCFG actually helps the loop being removed: > https://godbolt.org/z/5v7SXh > > But this doesn't even involve JumpThreading. > > Michael >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/a47f8e59/attachment.html>
Karl Rehm via llvm-dev
2020-Feb-03 21:09 UTC
[llvm-dev] Questions about jump threading optimization and what we can do
I think SimplifyCFG could be abusing the undef value for this. If num is defined before the loop, it no longer becomes optimized: https://godbolt.org/z/woHRQf On Mon, Feb 3, 2020 at 3:50 PM Karl Rehm <klrehm123 at gmail.com> wrote:> Hm. I assumed that JumpThreading would be the primary factor in optimizing > code like this. Guess not. I'll need to look into SimplifyCFG to see what > prevents it from doing the same thing to the other loop: > https://godbolt.org/z/F6NjdG > > On Mon, Feb 3, 2020 at 3:09 PM Michael Kruse <llvmdev at meinersbur.de> > wrote: > >> I assumed the LLVM-IR behind the godbolt link represented the C code >> you used before. >> >> SimplifyCFG actually helps the loop being removed: >> https://godbolt.org/z/5v7SXh >> >> But this doesn't even involve JumpThreading. >> >> Michael >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/9a2f7f49/attachment.html>
Michael Kruse via llvm-dev
2020-Feb-03 21:54 UTC
[llvm-dev] Questions about jump threading optimization and what we can do
Your code and the one you have seen in https://bugs.llvm.org/show_bug.cgi?id=44679 are structurally different. In that latter, setting n to a constant value causes a branch taken in the next iteration. Your's is a more classic for-loop from 0 to 2. It is ScalarEvolution's job to find this out. SimplyCFG job is just to normalize the IR into a form understood by ScalarEvolution. That is, ScalarEvolution is the primary engine enabling this. Michael Am Mo., 3. Feb. 2020 um 14:51 Uhr schrieb Karl Rehm <klrehm123 at gmail.com>:> > Hm. I assumed that JumpThreading would be the primary factor in optimizing code like this. Guess not. I'll need to look into SimplifyCFG to see what prevents it from doing the same thing to the other loop: https://godbolt.org/z/F6NjdG > > On Mon, Feb 3, 2020 at 3:09 PM Michael Kruse <llvmdev at meinersbur.de> wrote: >> >> I assumed the LLVM-IR behind the godbolt link represented the C code >> you used before. >> >> SimplifyCFG actually helps the loop being removed: >> https://godbolt.org/z/5v7SXh >> >> But this doesn't even involve JumpThreading. >> >> Michael
Karl Rehm via llvm-dev
2020-Feb-03 22:01 UTC
[llvm-dev] Questions about jump threading optimization and what we can do
Ok, thanks for the clarification. So looking into ScalarEvolution is what I'd look into if I wanted to optimize this a bit more? I'm mainly interested in how I'd go about "de-looping" this. On Mon, Feb 3, 2020 at 4:55 PM Michael Kruse <llvmdev at meinersbur.de> wrote:> Your code and the one you have seen in > https://bugs.llvm.org/show_bug.cgi?id=44679 are structurally > different. In that latter, setting n to a constant value causes a > branch taken in the next iteration. Your's is a more classic for-loop > from 0 to 2. It is ScalarEvolution's job to find this out. SimplyCFG > job is just to normalize the IR into a form understood by > ScalarEvolution. That is, ScalarEvolution is the primary engine > enabling this. > > Michael > > Am Mo., 3. Feb. 2020 um 14:51 Uhr schrieb Karl Rehm <klrehm123 at gmail.com>: > > > > Hm. I assumed that JumpThreading would be the primary factor in > optimizing code like this. Guess not. I'll need to look into SimplifyCFG to > see what prevents it from doing the same thing to the other loop: > https://godbolt.org/z/F6NjdG > > > > On Mon, Feb 3, 2020 at 3:09 PM Michael Kruse <llvmdev at meinersbur.de> > wrote: > >> > >> I assumed the LLVM-IR behind the godbolt link represented the C code > >> you used before. > >> > >> SimplifyCFG actually helps the loop being removed: > >> https://godbolt.org/z/5v7SXh > >> > >> But this doesn't even involve JumpThreading. > >> > >> Michael >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/56c98543/attachment.html>