Skip to content

[Codegen] Fix if_then_else codegen - #16242

Merged
jinhongyii merged 5 commits into
apache:mainfrom
spectrometerHBH:fix
Jan 4, 2024
Merged

jinhongyii merged 5 commits into
apache:mainfrom
spectrometerHBH:fix

Conversation

@spectrometerHBH

@spectrometerHBH spectrometerHBH commented Dec 14, 2023 •

Copy link
Copy Markdown
Contributor
  • Evaluating op.if_then_else with a?b:c is potentially dangerous as it might evaluate expressions in branches without a guard of condition.

  • While loop condition expression might require several var bindings generated, so we correct the while loop codegen from while (cond) to while (True)

Comment thread src/runtime/ndarray.cc Outdated
@vinx13

vinx13 commented Dec 17, 2023

Copy link
Copy Markdown
Member

isn't short circuiting the defined behavior for ternary expression?

@spectrometerHBH

Copy link
Copy Markdown
Contributor Author

isn't short circuiting the defined behavior for ternary expression?

When generating codes for a?b:c, there might be bindings for b or c generated ahead. These binding codes are not protected by condition a.

@jinhongyii
jinhongyii merged commit ae7d9db into apache:main Jan 4, 2024
junrushao added a commit to junrushao/tvm that referenced this pull request Jan 7, 2024
* fix

* lint

* fix while loop

* clean

* clean

---------

Co-authored-by: Junru Shao <junrushao1994@gmail.com>
@ysh329

ysh329 commented Feb 17, 2025

Copy link
Copy Markdown
Contributor

isn't short circuiting the defined behavior for ternary expression?

When generating codes for a?b:c, there might be bindings for b or c generated ahead. These binding codes are not protected by condition a.

Hi, bohan, I recently am supporting Ternary Operator(like cond?true_branch:false_branch) in our device. I don't understand this modification. Can u explain this with a case? Thanks a lot!

tlopex pushed a commit that referenced this pull request Sep 10, 2026
… code (#20285)

## Problem

Since #16242, the `if_then_else` builtin call is expanded into an
if/else statement. When printing the condition, the codegen wraps it in
another pair of parentheses even though it is already parenthesized,
producing `if ((i == 0))`.

## Impact

The doubled parentheses trigger clang's `-Wparentheses-equality` warning
under `-Wall`/`-Wparentheses`, which is noisy for downstream users who
compile TVM-generated C sources with strict warning settings.
Correctness is not affected — the issue is cosmetic.

## Solution

Reuse the same leading/trailing parenthesis check as the existing
`IfThenElseNode` handling in `CodeGenC`, so a condition that already
starts and ends with parentheses is printed as-is. The generated code
now reads `if (i == 0)`.

Since `CodeGenC` is the shared base of all C-style backends (CUDA,
Metal, ROCm, Vulkan, WebGPU, Hexagon), this fix covers them all at once.

## Testing

- Added a regression test
`test_if_then_else_avoids_extraneous_parentheses` in
`tests/python/codegen/test_target_codegen_c_host.py`, which asserts the
generated C source contains no `if ((` and validates the runtime result.
- Ran the full `test_target_codegen_c_host.py` suite on aarch64 Linux
with a local build: 10/10 passed.
- `pre-commit` (clang-format, ruff-check, ruff-format) passed on the
changed files.

Co-authored-by: hejun <hejun72@outlook.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants