summaryrefslogtreecommitdiff
path: root/compiler/nativeGen/BlockLayout.hs
diff options
context:
space:
mode:
authorJosh Meredith <joshmeredith2008@gmail.com>2019-12-04 23:39:28 +1100
committerJosh Meredith <joshmeredith2008@gmail.com>2019-12-04 23:39:28 +1100
commita8435165b84c32fd2ebdd1281dd6ee077e07ad5a (patch)
tree791936d014aeaa26174c2dcbef34c14f3329dd04 /compiler/nativeGen/BlockLayout.hs
parent7805441b4d5e22eb63a501e1e40383d10380dc92 (diff)
parentf03a41d4bf9418ee028ecb51654c928b2da74edd (diff)
downloadhaskell-wip/binary-readerT.tar.gz
Merge branch 'master' into wip/binary-readerTwip/binary-readerT
Diffstat (limited to 'compiler/nativeGen/BlockLayout.hs')
-rw-r--r--compiler/nativeGen/BlockLayout.hs7
1 files changed, 3 insertions, 4 deletions
diff --git a/compiler/nativeGen/BlockLayout.hs b/compiler/nativeGen/BlockLayout.hs
index 56e3177dd8..ba15e0063f 100644
--- a/compiler/nativeGen/BlockLayout.hs
+++ b/compiler/nativeGen/BlockLayout.hs
@@ -76,10 +76,10 @@ import Control.Monad (foldM)
We have a CFG with edge weights based on which we try to place blocks next to
each other.
- Edge weights not only represent likelyhood of control transfer between blocks
+ Edge weights not only represent likelihood of control transfer between blocks
but also how much a block would benefit from being placed sequentially after
it's predecessor.
- For example blocks which are preceeded by an info table are more likely to end
+ For example blocks which are preceded by an info table are more likely to end
up in a different cache line than their predecessor and we can't eliminate the jump
so there is less benefit to placing them sequentially.
@@ -359,7 +359,7 @@ takeL n (BlockChain blks) =
-- While we could take into account the space between the two blocks which
-- share an edge this blows up compile times quite a bit. It requires
-- us to find all edges between two chains, check the distance for all edges,
--- rank them based on the distance and and only then we can select two chains
+-- rank them based on the distance and only then we can select two chains
-- to combine. Which would add a lot of complexity for little gain.
--
-- So instead we just rank by the strength of the edge and use the first pair we
@@ -891,4 +891,3 @@ lookupDeleteUFM :: Uniquable key => UniqFM elt -> key
lookupDeleteUFM m k = do -- Maybe monad
v <- lookupUFM m k
return (v, delFromUFM m k)
-