You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then lookupVarEnv doesn't get inlined (because it is now too big) and every time it's called a function is allocated.
OTOH, if the function is like how it was before then the wrapper gets inlined into lookupVarEnv, lookupVarEnv is the inlined and the worker subsequently inlined into the right place.
The text was updated successfully, but these errors were encountered:
It's not clear to me that rolling back the commit here would bring a stable improvement for GHC. The discussion #794#800 seemed to show that there were some good reasons, backed up with measurements.
Commit e6fbb98 causes GHCs performance tests to fail. (https://gitlab.haskell.org/ghc/ghc/-/jobs/958207)
The issue for us in
Data.IntMap.Internal.lookup
, the modification of this function makes it small enough that Worker/Wrapper doesn't trigger on it:https://gist.github.com/mpickering/74590e7ababb7a82abc4b04749456ccd
The consequence is that different things get inlined into
lookupVarEnv
(a function in GHC)https://gist.github.com/mpickering/cd5a3c7baf1ae678d1a830cf76b2c56e
Then
lookupVarEnv
doesn't get inlined (because it is now too big) and every time it's called a function is allocated.OTOH, if the function is like how it was before then the wrapper gets inlined into
lookupVarEnv
,lookupVarEnv
is the inlined and the worker subsequently inlined into the right place.The text was updated successfully, but these errors were encountered: