Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow call_intrin to call an LLVM intrinsic with void return type. #7048

Merged
merged 5 commits into from
Sep 24, 2022

Conversation

zvookin
Copy link
Member

@zvookin zvookin commented Sep 23, 2022

Specific use case is calling vector predicated store. Factored out of the vector predication branch for ease of code review and such.

@zvookin zvookin requested a review from abadams September 23, 2022 22:13
@zvookin zvookin changed the title Allow call_intrin to call an LLVM inrinsic with void return type. Allow call_intrin to call an LLVM intrinsic with void return type. Sep 23, 2022
Copy link
Contributor

@steven-johnson steven-johnson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM pending green

@steven-johnson
Copy link
Contributor

(but please fix clang-format)

@zvookin zvookin merged commit a817414 into main Sep 24, 2022
@zvookin zvookin deleted the void_call_intrinsics branch September 24, 2022 00:16
ardier pushed a commit to ardier/Halide-mutation that referenced this pull request Mar 3, 2024
…alide#7048)

Have ```CodeGen_LLVM::get_vector_type``` return the void type if passed the void type as a scalar base. This makes it possible to call intrinsics returning void via ```CodeGenn_LLVM::call_intrin```.

Should be very safe as currently this anything doing this would fail inside the routine. The change breaks the invariant that any thing returned from get_vector_type is a vector type, but propagating void for function return types is a pretty standard behavior and if this was not intended, it will very likely fail just outside this instead of having failed inside the use. I.e. very low chance of spurious errors from this.
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.

3 participants