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

Add checks to prevent people from using negative split factors #8076

Merged
merged 3 commits into from
Feb 11, 2024

Conversation

abadams
Copy link
Member

@abadams abadams commented Feb 7, 2024

Our analysis passes assume that loop maxes are greater than loop mins, so negative split factors cause sufficient havoc that not even output bounds queries are safe. These are therefore checked on pipeline entry.

This is a new way for output bounds queries to throw errors (in addition to the buffer pointers themselves being null, and maybe some buffer constraints). Testing this, I realized these errors were getting thrown twice, because the output buffer bounds query in Pipeline::realize was built around two recursive calls to realize, and both were calling the custom error handler. In addition to reporting errors in this class twice, this implies several other inefficiencies, e.g. jit call args were being prepped twice. I reworked it to be built around two calls to call_jit_code instead.

Fixes #7938

Our analysis passes assume that loop maxes are greater than loop mins,
so negative split factors cause sufficient havoc that not even output
bounds queries are safe. These are therefore checked on pipeline entry.

This is a new way for output bounds queries to throw errors (in addition
to the buffer pointers themselves being null, and maybe some buffer
constraints). Testing this, I realized these errors were getting thrown
twice, because the output buffer bounds query in Pipeline::realize was
built around two recursive calls to realize, and both were calling the
custom error handler. In addition to reporting errors in this class
twice, this implies several other inefficiencies, e.g. jit call args
were being prepped twice. I reworked it to be built around two calls to
call_jit_code instead.

Fixes #7938
@steven-johnson
Copy link
Contributor

~every wasm test is failing with Internal Error at [third_party/halide/halide/src/JITModule.cpp:1193](https://cs.corp.google.com/piper///depot/google3/third_party/halide/halide/src/JITModule.cpp?l=1193&ws=tap-presubmit-server/155770392&snapshot=2) triggered by user code at : Condition failed: argv_wrapper != nullptr:

@abadams
Copy link
Member Author

abadams commented Feb 8, 2024

I guess that means that the wasm tests don't have the arch set right for one of my new calls to call_jit_code

It has to be the same as the cached target in the receiving object
anyway
@steven-johnson steven-johnson merged commit 9c3615b into main Feb 11, 2024
19 checks passed
@steven-johnson steven-johnson deleted the abadams/split_factors_must_be_positive branch February 11, 2024 18:41
ardier pushed a commit to ardier/Halide-mutation that referenced this pull request Mar 3, 2024
…e#8076)

* Add checks to prevent people from using negative split factors

Our analysis passes assume that loop maxes are greater than loop mins,
so negative split factors cause sufficient havoc that not even output
bounds queries are safe. These are therefore checked on pipeline entry.

This is a new way for output bounds queries to throw errors (in addition
to the buffer pointers themselves being null, and maybe some buffer
constraints). Testing this, I realized these errors were getting thrown
twice, because the output buffer bounds query in Pipeline::realize was
built around two recursive calls to realize, and both were calling the
custom error handler. In addition to reporting errors in this class
twice, this implies several other inefficiencies, e.g. jit call args
were being prepped twice. I reworked it to be built around two calls to
call_jit_code instead.

Fixes halide#7938

* Add test to cmakelists

* Remove pointless target arg to call_jit_code

It has to be the same as the cached target in the receiving object
anyway
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.

A schedule with a split factor of zero compiles to a no-op stage
2 participants