[llvm-bugs] [Bug 35405] New: Coroutine suspend/resume in loop not always optimized away

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35405

            Bug ID: 35405
           Summary: Coroutine suspend/resume in loop not always optimized
                    away
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: strager at fb.com
                CC: llvm-bugs at lists.llvm.org

It seems like Clang+LLVM has some trouble optimizing my code. In a loop, I am
suspending a coroutine then calling
std::experimental::coroutine_handle::resume. See main_v0_loop in the program
below.

I expect Clang+LLVM to optimize the loop away completely, but the generated
code repeatedly suspends and resumes the coroutine.

Clang+LLVM *is* able to properly optimize similar loops. It also is able to
properly optimize the loop if I unroll the loop, but not always. See the other
main_* functions in the program below.

Let me know if (and how) I should reduce the program further.

Program:
https://godbolt.org/g/m2YSsW

main_v0_loop: gen_pop-push 1000 times, then gen_pop once (suspending the
coroutine forever). Conceptually, the gen_pop-s are done asynchronously on a
different "thread".
main_v1_loop: push-gen_pop 1000 times. Conceptually, the gen_pop-s are done
synchronously on the main "thread".
main_v2_loop: push-pop 1000 times.
main_v3_loop: push-gen_pop 1000 times, then gen_pop once (suspending the
coroutine forever). Conceptually, the gen_pop-s are done asynchronously on a
different "thread".

main_v0_single: Like main_v0_loop, but iterate only once and manually unroll
the loop.
main_v1_single: Like main_v1_loop, but iterate only once and manually unroll
the loop.
main_v2_single: Like main_v2_loop, but iterate only once and manually unroll
the loop.
main_v3_single: Like main_v3_loop, but iterate only once and manually unroll
the loop.

main_v0_triple: Like main_v0_loop, but iterate only 3 times and manually unroll
the loop.
main_v1_triple: Like main_v1_loop, but iterate only 3 times and manually unroll
the loop.
main_v2_triple: Like main_v2_loop, but iterate only 3 times and manually unroll
the loop.
main_v3_triple: Like main_v3_loop, but iterate only 3 times and manually unroll
the loop.

Clang+LLVM version: 6.0.0 trunk 318899 (according to Godbolt's Compiler
Explorer <https://godbolt.org/>)

Clang driver flags: -std=c++17 -fcoroutines-ts -stdlib=libc++ -O2 -DNDEBUG=1
-fno-exceptions

Platform: Linux x86_64 (I think; I used Godbolt's Compiler Explorer
<https://godbolt.org/>)

Expected results:
X: The generated code for main_v0_*, main_v1_*, and main_v3_* has no calls to
operator new or operator delete (due to the coroutine created by pop_once or
keep_popping).
Y: The generated code for all functions has no indirect jumps (due to the call
to coroutine_handle::resume).
Z: The generated code for all functions is just 'ret', since the function has
no side effects.

Observed results:
X: As expected, the generated code for all functions has no calls to operator
new or operator delete.
Y: The generated code for main_v0_loop, main_v0_triple, main_v3_loop, and
main_v3_triple has indirect jumps. The generated code for all other functions
has no indirect jumps as expected.
Z: The generated code for main_v0_loop, main_v0_triple, main_v3_loop, and
main_v3_triple is non-trivial. The generated code for all other functions is
just 'ret' as expected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171124/beb139b6/attachment.html>