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

Unification results for index expressions are non-deterministic #602

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

Unification results for index expressions are non-deterministic #602

SamirDroubi opened this issue Mar 26, 2024 · 0 comments

Comments

@SamirDroubi
Copy link
Collaborator

I have noticed on multiple occasions that unification results are non-deterministic. For example, unifying some access A[i, j] with reg :[f32][1] might be A[i:i+1][j] or A[i,j:j+1]. Here is an another example where the codegen results is different:

ssyrk_rm_l_stride_1_mk_A_pack(ctxt,-24 * ((23 + N) / (24)) + -(24 * io) + N + 24,512,(struct exo_win_2f32c){ &A.data[(24 * ((23 + N) / 24) + 24 * io + -24) * (A.strides[0]) + 512 * ko], { A.strides[0], 1 } },packed_A);
ssyrk_rm_l_stride_1_mk_A_pack(ctxt,-24 * ((23 + N) / (24)) + N + -(24 * io) + 24,512,(struct exo_win_2f32c){ &A.data[(24 * ((23 + N) / 24) + 24 * io + -24) * (A.strides[0]) + 512 * ko], { A.strides[0], 1 } },packed_A);

Most of the times, we get around these issues by simplifying (which would sort the operands during normalization resulting in a deterministic output), but sometimes we hit some edge cases that our simplification doesn't handle and you end up in a similar case as the above.

The main problem with this is that it makes is hard to write tests that checks the output of scheduling/codegen.

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

No branches or pull requests

1 participant