Compiling the certifier with profiling enabled results in a GHC panic

[basetunnel]

@ana-pantilie identified an issue with the build process of the certifier when enabling profiling:

On latest plutus master:

nix develop .#profiled
cabal build plutus-metatheory --enable-profiling

You should at some point see an error like:

...
[ 24 of 284] Compiling MAlonzo.Code.Data.Sign.Base ( src/MAlonzo/Code/Data/Sign/Base.hs, /home/ana/Workspace/IOG/plutus/dist-newstyle/build/x86_64-linux/ghc-9.6.7/plutus-metatheory-1.54.0.0/build/MAlonzo/Code/Data/Sign/Base.p_o )

<no location info>: error:
    panic! (the 'impossible' happened)
  GHC version 9.6.7:
        getStgArgFromTrivialArg
  (scc<d_'42''45'1'45'rawGroup_24> d__'42'__14)
  `cast` (SelCo:Fun(arg)
              (Sub Univ(nominal CorePrep
                        :: (T_Sign_6 -> T_Sign_6 -> T_Sign_6)
                           -> Any -> (T_Sign_6 -> T_Sign_6) -> T_RawGroup_96, (Any
                                                                               -> Any -> Any)
                                                                              -> Any
                                                                              -> (Any -> Any)
                                                                              -> T_RawGroup_96))
          :: (T_Sign_6 -> T_Sign_6 -> T_Sign_6) ~R# (Any -> Any -> Any))
  Call stack:
      CallStack (from HasCallStack):
        callStackDoc, called at compiler/GHC/Utils/Panic.hs:189:37 in ghc:GHC.Utils.Panic
        pprPanic, called at compiler/GHC/CoreToStg.hs:587:13 in ghc:GHC.CoreToStg
  CallStack (from HasCallStack):
    panic, called at compiler/GHC/Utils/Error.hs:454:29 in ghc:GHC.Utils.Error


Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug 

It was reproduced by @luite:

Thanks, I can reproduce it with 9.6.7 inside and outside nix. 9.12.2 compiles it succesfully. I'll check if this has already been fixed

[luite]

This bug affects GHC 9.6.x and 9.8.x. It is related to handling of ticks around unsafeCoerce: A tick appears in a place that the CoreToStg pass doesn't expect. I was able to reduce the reproducer to a single file of ~70 lines.

There have been some changes in handling of unsafeCoerce in 9.10+, but I haven't found any fix in the GHC commit history addressing this specific issue. But I also haven't been able to reproduce this on 9.10+.

Since this has only been reproduced with 9.6.x/9.8.x and no further releases are currently planned in those GHC branches, I think the best thing to do is adding a workaround with some CPP for 9.6/9.8 (~10 lines). If I later find/fix a remaining underlying issue in newer GHC I'll add a link to it in this ticket.

[ana-pantilie]

More discussion https://input-output-rnd.slack.com/archives/C21UF2WVC/p1763034036002919?thread_ts=1762333018.114269&cid=C21UF2WVC

[luite]

It's possible to make -fprof-auto profiling work again by manually patching the file plutus-metatheory/src/MAlonzo/RTE.hs:

diff --git a/plutus-metatheory/src/MAlonzo/RTE.hs b/plutus-metatheory/src/MAlonzo/RTE.hs
index b354f26a7..cc6db8609 100644
--- a/plutus-metatheory/src/MAlonzo/RTE.hs
+++ b/plutus-metatheory/src/MAlonzo/RTE.hs
@@ -1,3 +1,4 @@
+{-# LANGUAGE CPP #-}
 {-# LANGUAGE PolyKinds #-}
 
 module MAlonzo.RTE where
@@ -17,11 +18,20 @@ import Unsafe.Coerce ( unsafeCoerce )
 
 type AgdaAny = GHC.Any
 
+-- Work around a bug in GHC 9.6.x and 9.8.x handling profiling ticks around
+-- unsafeCoerce. See https://github.com/IntersectMBO/plutus/issues/7415
+#if defined(PROFILING) && __GLASGOW_HASKELL__ >= 906 && __GLASGOW_HASKELL__ < 910
+{-# INLINE [1] coe #-}
+coe :: a -> b
+coe x = {-# SCC "coe" #-} unsafeCoerce x
+{-# RULES "coerce-id" forall (x :: a) . coe x = x #-}
+#else
 -- Special version of coerce that plays well with rules.
 {-# INLINE [1] coe #-}
 coe :: a -> b
 coe = unsafeCoerce
 {-# RULES "coerce-id" forall (x :: a) . coe x = x #-}
+#endif
 
 -- Builtin QNames.
 data QName = QName { nameId, moduleId :: Integer, qnameString :: String, qnameFixity :: Fixity }

This file is generated by Agda, so unfortunately we cannot apply this patch directly.