diff options
Diffstat (limited to 'compiler/coreSyn/CoreUnfold.hs')
| -rw-r--r-- | compiler/coreSyn/CoreUnfold.hs | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/compiler/coreSyn/CoreUnfold.hs b/compiler/coreSyn/CoreUnfold.hs index e55e12487b..1e4e39e289 100644 --- a/compiler/coreSyn/CoreUnfold.hs +++ b/compiler/coreSyn/CoreUnfold.hs @@ -260,7 +260,7 @@ the `UnfoldingGuidance`.) In the example, x's ug_arity is 0, so we should inline it at every use site. It's rare to have such an INLINE pragma (usually INLINE Is on -functions), but it's occasionally very important (Trac #15578, #15519). +functions), but it's occasionally very important (#15578, #15519). In #15519 we had something like x = case (g a b) of I# r -> T r {-# INLINE x #-} @@ -357,7 +357,7 @@ But given this decision it's vital that we do where g* is (for some strange reason) the loop breaker. If we don't occ-anal it when reading it in, we won't mark g as a loop breaker, and we may inline g entirely in body, dropping its binding, and leaving -the occurrence in f out of scope. This happened in Trac #8892, where +the occurrence in f out of scope. This happened in #8892, where the unfolding in question was a DFun unfolding. But more generally, the simplifier is designed on the @@ -395,7 +395,7 @@ GlobalIds. That seems (just) tolerable for the occurrence analysis that happens just before the Simplifier, but not for unfoldings, which are Linted independently. As a quick workaround, we disable binder swap in this module. -See Trac #16288 and #16296 for further plans. +See #16288 and #16296 for further plans. Note [Calculate unfolding guidance on the non-occ-anal'd expression] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -910,7 +910,7 @@ Simon M tried a MUCH bigger discount: (10 * (10 + n_val_args)), and said it was an "unambiguous win", but its terribly dangerous because a function with many many case branches, each finishing with a constructor, can have an arbitrarily large discount. This led to -terrible code bloat: see Trac #6099. +terrible code bloat: see #6099. Note [Unboxed tuple size and result discount] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -936,10 +936,10 @@ monadic combinators with continuation arguments, where inlining is quite important. But we don't want a big discount when a function is called many times -(see the detailed comments with Trac #6048) because if the function is +(see the detailed comments with #6048) because if the function is big it won't be inlined at its many call sites and no benefit results. Indeed, we can get exponentially big inlinings this way; that is what -Trac #6048 is about. +#6048 is about. On the other hand, for data-valued arguments, if there are lots of case expressions in the body, each one will get smaller if we apply @@ -1170,7 +1170,7 @@ certainlyWillInline dflags fn_info ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Don't claim that thunks will certainly inline, because that risks work duplication. Even if the work duplication is not great (eg is_cheap -holds), it can make a big difference in an inner loop In Trac #5623 we +holds), it can make a big difference in an inner loop In #5623 we found that the WorkWrap phase thought that y = case x of F# v -> F# (v +# v) was certainlyWillInline, so the addition got duplicated. |