[all-commits] [llvm/llvm-project] 66227b: [Coroutines] ABI Objects to improve code separatio...

[Tyler Nowicki via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 66227bf7ee2cd674e0306d9a1e9f1d86bc75123f
      https://github.com/llvm/llvm-project/commit/66227bf7ee2cd674e0306d9a1e9f1d86bc75123f
  Author: Tyler Nowicki <tyler.nowicki at amd.com>
  Date:   2024-10-03 (Thu, 03 Oct 2024)

  Changed paths:
    M llvm/include/llvm/Transforms/Coroutines/CoroSplit.h
    A llvm/lib/Transforms/Coroutines/ABI.h
    M llvm/lib/Transforms/Coroutines/CoroFrame.cpp
    M llvm/lib/Transforms/Coroutines/CoroInternal.h
    M llvm/lib/Transforms/Coroutines/CoroShape.h
    M llvm/lib/Transforms/Coroutines/CoroSplit.cpp
    M llvm/lib/Transforms/Coroutines/Coroutines.cpp

  Log Message:
  -----------
  [Coroutines] ABI Objects to improve code separation between different ABIs, users and utilities. (#109713)

This patch re-lands https://github.com/llvm/llvm-project/pull/109338 and
fixes the various test failures.

--- Original description ---

* Adds an ABI object class hierarchy to implement the coroutine ABIs
(Switch, Asyc, and Retcon{Once})
* The ABI object improves the separation of the code related to users,
ABIs and utilities.
* No code changes are required by any existing users.
* Each ABI overrides delegate methods for initialization, building the
coroutine frame and splitting the coroutine, other methods may be added
later.
* CoroSplit invokes a generator lambda to instantiate the ABI object and
calls the ABI object to carry out its primary operations. In a follow-up
change this will be used to instantiated customized ABIs according to a
new intrinsic llvm.coro.begin.custom.abi.
* Note, in a follow-up change additional constructors will be added to
the ABI objects (Switch, Asyc, and AnyRetcon) to allow a set of
generator lambdas to be passed in from a CoroSplit constructor that will
also be added. The init() method is separate from the constructor to
avoid duplication of its code. It is a virtual method so it can be
invoked by CreateAndInitABI or potentially CoroSplit::run(). I wasn't
sure if we should call init() from within CoroSplit::run(),
CreateAndInitABI, or perhaps hard code a call in each constructor. One
consideration is that init() can change the IR, so perhaps it should
appear in CoroSplit::run(), but this looks a bit odd. Invoking init() in
the constructor would result in the call appearing 4 times per ABI
(after adding the new constructors). Invoking it in CreateAndInitABI
seems to be a balance between these.

See RFC for more info:
https://discourse.llvm.org/t/rfc-abi-objects-for-coroutines/81057



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications