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

Support aliased input and output buffers #8161

Open
abadams opened this issue Mar 26, 2024 · 0 comments
Open

Support aliased input and output buffers #8161

abadams opened this issue Mar 26, 2024 · 0 comments
Labels
enhancement New user-visible features or improvements to existing features.

Comments

@abadams
Copy link
Member

abadams commented Mar 26, 2024

Currently you're not supposed to do this, because it's technically UB in the LLVM we generate, and it means the output can depend on the schedule. You're supposed to use undef instead for the pure definition, and then write your operation as an update definition on the output Func that reads values that were already in that buffer. But that doesn't always work. It can't work if there are other Funcs in between the input and output, because that would require a pipeline loop.

But people alias inputs and outputs all the time! It has caused several serious bugs in production that I'm aware of.

One solution might be an output.may_alias(input) call. It would error if it can't prove the schedule is safe from aliasing issues. One slightly over-conservative check would be: for every compute_root block that writes to an output and reads from an input that may alias that output, the schedule for the output and any intervening Funcs must not do any redundant recompute (e.g. ShiftInwards), and the operation must be element-wise in every Func between the output and that input.

A lower level check would be using a polyhedral clock vector, and saying that every load from an input coordinate must be earlier in time than any store to that output coordinate. But to do that robustly you start to need to worry about things like ILP solvers. I'd rather it were a simple(ish)-to-state constraint on the schedule.

But those solutions still wouldn't work if the output buffer is e.g. a crop of the input, so you can't line up coordinates like that. Hrm.

@abadams abadams added the enhancement New user-visible features or improvements to existing features. label Mar 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New user-visible features or improvements to existing features.
Projects
None yet
Development

No branches or pull requests

1 participant