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

UPLC case-of-case improvements #5966

Open
effectfully opened this issue May 8, 2024 · 5 comments
Open

UPLC case-of-case improvements #5966

effectfully opened this issue May 8, 2024 · 5 comments

Comments

@effectfully
Copy link
Contributor

effectfully commented May 8, 2024

After #5960 we have some left-overs:

  1. this example is incorrect and needs to be updated:
{- | A special case of case-of-case optimisation: transforms

@
    case ((force ifThenElse) b (constr t) (constr f)) alts
@

into

@
    force ifThenElse b (case (constr t) alts) (case (constr f) alts)
@

This is always an improvement.
-}

Plus, there's no explanation of what we do and why we do it.

  1. the PR added generation of extra force-delay pairs, why don't we see them in the existing golden tests? Those that were affected by the original PR introducing case-of-case? UPD: @ana-pantilie figured it out: it's because we know how case-of-case in PIR and so no suitable expression survives compilation of PIR to be transformed at the UPLC level. Thanks Ana!

  2. should we avoid generating force-delay pairs when branches are pure?

  3. what about PIR, do we have the same issue there that was fixed for UPLC?

  4. UPLC case-of-case is exponential in the same way as PIR case-of-case (see this and below).

@github-actions github-actions bot added the status: needs triage GH issues that requires triage label May 8, 2024
@zliu41
Copy link
Member

zliu41 commented May 9, 2024

Plus, there's no explanation of what we do and why we do it.

The name of the transformation is self-explanatory: this is basically case-of-case transformation. The reason it is useful is because it can trigger case-of-known-constructor transformation on case (constr t) and case (constr f).

@zliu41
Copy link
Member

zliu41 commented May 9, 2024

should we avoid generating force-delay pairs when branches are pure?

Yes, I think we already do that when compiling cases. Forces and delays are only added if at least one of the branches isn't pure.

@effectfully
Copy link
Contributor Author

The name of the transformation is self-explanatory: this is basically case-of-case transformation. The reason it is useful is because it can trigger case-of-known-constructor transformation on case (constr t) and case (constr f).

The name is self-explanatory, but the force-delay caveat was so obscure that if went through the review process without anybody noticing. This must be documented.

Yes, I think we already do that when compiling cases.

In the UPLC case-of-case transformation? Where?

@zliu41
Copy link
Member

zliu41 commented May 9, 2024

In the UPLC case-of-case transformation? Where?

I think it's in the compilation of Case in GHC Core into PIR, but it's the same idea.

@effectfully
Copy link
Contributor Author

Ah, I misunderstood, I thought you were saying it was already implemented for UPLC case-of-case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants