Add Tuple overloads for the non-arithmetic IROperator helpers - #9425
Open
abadams wants to merge 2 commits into
Open
Add Tuple overloads for the non-arithmetic IROperator helpers#9425abadams wants to merge 2 commits into
abadams wants to merge 2 commits into
Conversation
likely, likely_if_innermost, strict_float, memoize_tag, require, print and print_when now accept a Tuple and distribute across its elements. print and print_when print every element on one line, attached to the first element. The Python bindings get the same overloads. A FuncRef converts to both Expr and Tuple, so each helper (and select) also gets a FuncRef overload that goes through Tuple(f) and returns a Tuple. To keep single-valued Funcs usable in Expr contexts, one-element Tuples now convert implicitly to Expr, and Tuple(FuncRef) accepts single-valued Funcs. Tuple also gains begin()/end() so it can be iterated with range-for, and the Python Tuple gets __len__, __getitem__ and __iter__. Debug.h now forward-declares the Tuple stream printer next to the Expr one. Without it, streaming a Tuple from a file that doesn't include IRPrinter.h resolves to the Expr printer via the new conversion. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NZWjqjzMdpvXGhoxGKWLdJ
alexreinking
approved these changes
Sep 3, 2026
alexreinking
left a comment
Member
There was a problem hiding this comment.
Looks like a nice usability improvement! The Python binding strategy LGTM, too.
Adding begin()/end() to Tuple made several pre-existing index loops over Tuples convertible to range-based for; convert them. Also use empty() instead of size() == 0 in the Python print helper. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9425 +/- ##
==========================================
+ Coverage 69.93% 70.03% +0.09%
==========================================
Files 261 261
Lines 79410 79431 +21
Branches 19363 19364 +1
==========================================
+ Hits 55532 55626 +94
- Misses 17937 17950 +13
+ Partials 5941 5855 -86 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
selectalready works on Tuples, but there was no way to mark one side of a tuple-select aslikely, becauselikelyonly took anExpr. This came up in a pipeline where a tuple-valued select needed loop partitioning driven by one of its arms.What this does
Adds Tuple overloads that distribute across the elements for the IROperator helpers that don't imply any math:
likely,likely_if_innermost,strict_floatmemoize_tagrequireprint,print_when(all elements printed on one line, with the print attached to the first element)The arithmetic helpers deliberately don't get overloads, and nothing in
Internaldoes.FuncRefs and one-element Tuples
A
FuncRefconverts implicitly to bothExprandTuple, so a bare Tuple overload would have made existing calls likelikely(f(x))ambiguous. Each helper (and the existingselect(cond, FuncRef, FuncRef)) therefore gets aFuncRefoverload that dispatches on the tupleness of the Func by going throughTuple(f)and returning aTuple.To keep single-valued Funcs usable in Expr contexts, one-element Tuples now convert implicitly to
Expr(in the same spirit as one-dimensional RDoms converting to RVars), andTuple(FuncRef)accepts single-valued Funcs.selecton FuncRefs no longer errors on Tuple-valued Funcs as a result.Tuplealso gainsbegin()/end()so it can be iterated with range-for, and the Pythonhl.Tuplegets__len__,__getitem__and__iter__.Debug.h
Debug.hforward-declares theExprstream printer for every source file but not theTupleone. With the new conversion, streaming a Tuple from a file that doesn't includeIRPrinter.hsilently resolved to the Expr printer (and recursed inside the conversion's own error message). The Tuple printer is now declared alongside it.Tests
test/correctness/tuple_helpers.cppchecks each helper wraps every element in the right intrinsic, thatlikelyon a Tuple actually triggers loop partitioning, thatrequire/print/print_whenbehave at runtime, that FuncRefs of both single- and Tuple-valued Funcs resolve, and that one-element Tuples convert to Expr.test/error/tuple_to_expr.cppchecks that a multi-element Tuple refuses to convert.test_tuple_helpersiniroperator.py. The Pythonrequirebinding also now accepts string message args like the C++ one.🤖 Generated with Claude Code
https://claude.ai/code/session_01NZWjqjzMdpvXGhoxGKWLdJ