llvm dev - Jan 2020 - Questions about jump threading optimization and what we can do

Since the bug report here: https://bugs.llvm.org/show_bug.cgi?id=44679 I've
been thinking about cases like it, such as: https://godbolt.org/z/Fwq8mn

I wonder what we can do about this in a general sense. As far as I can
tell, the jump threading algorithm is *really* conservative, which is one
reason this isn't working as well as I'd hope; however, we don't
want to
produce irreducible control flow that the other passes would work less
effectively on. Thoughts?

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200130/579f396d/attachment.html>

On Fri, Jan 31, 2020 at 12:47 AM Karl Rehm via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Since the bug report here: https://bugs.llvm.org/show_bug.cgi?id=44679
I've been thinking about cases like it, such as:
https://godbolt.org/z/Fwq8mn
>
> I wonder what we can do about this in a general sense. As far as I can
tell, the jump threading algorithm is *really* conservative, which is one reason
this isn't working as well as I'd hope; however, we don't want to
produce irreducible control flow that the other passes would work less
effectively on. Thoughts?
Just brainstorming, really, but what about running a less conservative
version of JumpThreading later, _after_ loop passes have run?

Cheers,
Nicolai


>
> - Karl
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

On 01/30, Karl Rehm via llvm-dev wrote:
> Since the bug report here: https://bugs.llvm.org/show_bug.cgi?id=44679
I've
> been thinking about cases like it, such as: https://godbolt.org/z/Fwq8mn
> 
> I wonder what we can do about this in a general sense. As far as I can
> tell, the jump threading algorithm is *really* conservative, which is one
> reason this isn't working as well as I'd hope; however, we
don't want to
> produce irreducible control flow that the other passes would work less
> effectively on. Thoughts?
I'm confused. In your godbold link you run it with O0 which disables
almost all transformations. If we take the IR, remove the optnone
attribute, run mem2reg and jump-threading we get what I think is
reasonable:
  https://godbolt.org/z/u3fcTZ

Please correct me if I misunderstand anything here.

Cheers,
  Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200202/0f622ce6/attachment.sig>

Holy crap, I completely missed that. I'm sorry! That's my fault.

On Sun, Feb 2, 2020 at 12:15 PM Johannes Doerfert <jdoerfert at anl.gov>
wrote:
> On 01/30, Karl Rehm via llvm-dev wrote:
> > Since the bug report here: https://bugs.llvm.org/show_bug.cgi?id=44679
> I've
> > been thinking about cases like it, such as:
https://godbolt.org/z/Fwq8mn
> >
> > I wonder what we can do about this in a general sense. As far as I can
> > tell, the jump threading algorithm is *really* conservative, which is
one
> > reason this isn't working as well as I'd hope; however, we
don't want to
> > produce irreducible control flow that the other passes would work less
> > effectively on. Thoughts?
>
> I'm confused. In your godbold link you run it with O0 which disables
> almost all transformations. If we take the IR, remove the optnone
> attribute, run mem2reg and jump-threading we get what I think is
> reasonable:
>   https://godbolt.org/z/u3fcTZ
>
> Please correct me if I misunderstand anything here.
>
> Cheers,
>   Johannes
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200202/34db416d/attachment.html>