Simplification pass assumes laziness, resulting in miscompilation

Question

Simplification pass assumes laziness, resulting in miscompilation

L-as opened this issue 2 years ago · comments

Summary

While UPLC/PLC/PIR are strict, a simplification pass assumes the code is to be interpreted lazily, thus resulting in the following behaviour:
let c x _ = x in c True (error ()) will not err. If you however set it to const, it will err, because it's not simplified (for some arcane reason).

Concrete example in fork of Plutus: https://github.com/mlabs-haskell/plutus/commits/las/miscompilation

Do you have a proposed solution for this issue?

It's not clear to me whether it's GHC doing this or a Plutus library. In the former case, disable the optimisation pass, however this would lead to decreased efficiency, in the latter case, keep track of whether it's possible for the term to err.

System info

No response

Michael Peyton Jones · Answer 1 · Fri Aug 26 2022 17:59:50 GMT+0800 (China Standard Time)

Sorry, can you be more specific? Is this a PIR program? A Haskell program?

Unfortunately we can't stop GHC from touching the program entirely, so if this is Haskell it may indeed be something that GHC is doing.

Las Safin · Answer 2 · Fri Aug 26 2022 18:09:30 GMT+0800 (China Standard Time)

I've posted a link to a fork in the summary where I've added goldens for the test.
Another link: mlabs-haskell@eee1404#diff-1eec071a1e24882fcf29911ff286bec003f983927819ae99ad431fdf75867799
It's a Haskell program.

Michael Peyton Jones · Answer 3 · Fri Aug 26 2022 18:44:46 GMT+0800 (China Standard Time)

That's helpful, thanks.

effectfully · Answer 4 · Sun Mar 05 2023 11:35:08 GMT+0800 (China Standard Time)

This was brought into the sprint, but hasn't been worked on yet. Chances are, it'll take a bit more time for us to get to this issue, I will keep you updated.

Marty Stumpf · Answer 5 · Tue May 02 2023 01:27:54 GMT+0800 (China Standard Time)

PR #5280 shows that with the noinline pragma the evaluation results for the two examples are now the same. I.e., it IS GHC's inliner that causes the inconsistency.

For now, users will have to turn off the GHC inliner by hand with the noinline pragma for affected functions. For example:

trueOrError :: CompiledCode Bool
trueOrError = $$(compile [|| c True (P.error () :: Bool) ||])
  where
    {-# NOINLINE c #-}
    c x _ = x

The team will be discussing and exploring better solutions. We welcome your input as well.

effectfully · Answer 6 · Tue May 16 2023 10:56:26 GMT+0800 (China Standard Time)

More discussion in this ADR.

@zliu41 do you have an idea on what we should do with this issue?

Ziyang Liu · Answer 7 · Tue May 16 2023 11:14:14 GMT+0800 (China Standard Time)

Strict is the only option. The other option (nonstrict) requires a way to prevent GHC from inlining things but that isn't currently possible.

effectfully · Answer 8 · Tue May 16 2023 21:46:03 GMT+0800 (China Standard Time)

@zliu41 should we keep this issue open or advertise using Strict and close the issue or something else? I'm just not sure how proceed with this specific GitHub issue.

Ziyang Liu · Answer 9 · Tue May 16 2023 21:56:33 GMT+0800 (China Standard Time)

Let's keep it open until we merge #5292 and start telling people to use Strict.

effectfully · Answer 10 · Tue Jul 18 2023 07:45:34 GMT+0800 (China Standard Time)

Let's keep it open until we merge #5292 and start telling people to use Strict.

@zliu41 we aren't telling people to use Strict quite yet, right?

Ziyang Liu · Answer 11 · Thu Jul 20 2023 00:12:39 GMT+0800 (China Standard Time)

@zliu41 we aren't telling people to use Strict quite yet, right?

Right. The internal ticket tracking this is PLT-5830.

effectfully · Answer 12 · Wed Nov 22 2023 19:26:29 GMT+0800 (China Standard Time)

The internal ticket tracking this is PLT-5830.

It's merged now (has been for a while) and hence we can close this issue with the following general advice: use Strict, otherwise GHC will misbehave.