Closed langston-barrett closed 1 month ago
Huh, GHC 9.8 yields:
Error: cabal: Failed to build macaw-ppc-symbolic-0.1.0.0 (which is required by
test:macaw-ppc-symbolic-tests from macaw-ppc-symbolic-0.1.0.0). The build
process was killed (i.e. SIGKILL). The typical reason for this is that there
is not enough memory available (e.g. the OS killed a process using lots of
memory).
Wow. I thought maybe that this was a CI fluke, but no: it's very reproducible. I can even reproduce it locally with my (fairly powerful) laptop.
The problem arises when compiling the MS.updateReg = archUpdateReg
fields of GenArchVals
in the GenArchInfo
instnaces for AnyPPC V32
or AnyPPC V64
in Data.Macaw.Symbolic.PPC
. Interestingly, if you mark Regs.updateReg
as INLINE
:
diff --git a/macaw-ppc-symbolic/src/Data/Macaw/PPC/Symbolic/Regs.hs b/macaw-ppc-symbolic/src/Data/Macaw/PPC/Symbolic/Regs.hs
index 3aeafb81..0931ff40 100644
--- a/macaw-ppc-symbolic/src/Data/Macaw/PPC/Symbolic/Regs.hs
+++ b/macaw-ppc-symbolic/src/Data/Macaw/PPC/Symbolic/Regs.hs
@@ -427,6 +427,7 @@ lookupReg r asgn =
Nothing -> X.throwM (MissingRegisterInState (Some r))
Just pair -> return (asgn Ctx.! MSB.crucibleIndex pair)
+{-# INLINE updateReg #-}
updateReg :: forall v ppc m f tp
. (MP.KnownVariant v,
ppc ~ MP.AnyPPC v,
Then the problem goes away. Hm...
Yeah, I also see this locally with GHC 9.8. Seems like a regression in the compiler?
@RyanGlScott Are you good with merging this with the INLINE
workaround, or would you like for us to do some additional digging into what exactly caused this compiler performance issue?
I did spend some time attempting to minimize the issue, but I was ultimately unsuccessful. I do think that this is worth reporting upstream to GHC, so I've opened https://gitlab.haskell.org/ghc/ghc/-/issues/25301 to track this. That being said, I don't think we should wait until that is fixed before proceeding.
Could you cite this GHC issue in the comments next to updateReg
? Then I think this would be ready to land.
Like #444, but for PPC.