[llvm-dev] Questions about jump threading optimization and what we can do

Karl Rehm via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 3 14:01:31 PST 2020


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>


More information about the llvm-dev mailing list