[Doc] Remove checkpoint fixme#755
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e8663cd86a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| ## Composable `@qd.func` ops | ||
|
|
||
| Every algorithm is a composable `@qd.func` (e.g. `reduce_add`, `sort`): call it at the **top level** of your own `@qd.kernel`, so the op is captured into the same kernel / graph as your surrounding phases. The function is annotated with `requires_top_level=True`, so attempting to use it outside of top level will throw an exception at compile time. Note that within a `qd.loop_do_while` counts as being at top-level [FIXME: add qd.checkpoint here too, once/when we merge qd.checkpoint]. | ||
| Every algorithm is a composable `@qd.func` (e.g. `reduce_add`, `sort`): call it at the **top level** of your own `@qd.kernel`, so the op is captured into the same kernel / graph as your surrounding phases. The function is annotated with `requires_top_level=True`, so attempting to use it outside of top level will throw an exception at compile time. Note that within a `qd.loop_do_while` or `qd.checkpoint` counts as being at top-level. |
There was a problem hiding this comment.
This new wording tells users that a qd.checkpoint body counts as top level for composable algorithms, but the checkpoint transformer rejects any non-docstring bare ast.Expr in a checkpoint body before the call is lowered (checkpoint_transformer.py lines 247-263). Since calls such as qd.algorithms.reduce_add(...) or qd.algorithms.sort(...) are bare expression statements in the documented usage pattern, placing them directly under with qd.checkpoint(...): raises QuadrantsSyntaxError, and wrapping them in a normal for then violates requires_top_level=True. Please qualify this or document the supported wrapping pattern, otherwise the docs advertise an API shape that currently fails at compile time.
Useful? React with 👍 / 👎.
| ## Composable `@qd.func` ops | ||
|
|
||
| Every algorithm is a composable `@qd.func` (e.g. `reduce_add`, `sort`): call it at the **top level** of your own `@qd.kernel`, so the op is captured into the same kernel / graph as your surrounding phases. The function is annotated with `requires_top_level=True`, so attempting to use it outside of top level will throw an exception at compile time. Note that within a `qd.loop_do_while` counts as being at top-level [FIXME: add qd.checkpoint here too, once/when we merge qd.checkpoint]. | ||
| Every algorithm is a composable `@qd.func` (e.g. `reduce_add`, `sort`): call it at the **top level** of your own `@qd.kernel`, so the op is captured into the same kernel / graph as your surrounding phases. The function is annotated with `requires_top_level=True`, so attempting to use it outside of top level will throw an exception at compile time. Note that within a `qd.loop_do_while` or `qd.checkpoint` counts as being at top-level. |
There was a problem hiding this comment.
The bot comment looks legit.
2 participants
Issue: #
Brief Summary
copilot:summary
Walkthrough
copilot:walkthrough