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

Michael Kruse via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 3 09:28:57 PST 2020


How does the code you would like to have look like? I don't see a
relevant difference compared to gcc:
https://godbolt.org/z/F-oah4
(clang unnecessarily introduces another temporary register, but that
seems unrelated)

Michael

Am So., 2. Feb. 2020 um 18:24 Uhr schrieb Karl Rehm via llvm-dev
<llvm-dev at lists.llvm.org>:
>
> Here's a better example. https://godbolt.org/z/fpTyFS
> I don't know what exactly you would need to change in JumpThreading to improve this, but I'm open to ideas.
>
> On Sun, Feb 2, 2020 at 12:45 PM Karl Rehm <klrehm123 at gmail.com> wrote:
>>
>> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list