diff options
author | simonpj@microsoft.com <unknown> | 2008-01-23 13:40:12 +0000 |
---|---|---|
committer | simonpj@microsoft.com <unknown> | 2008-01-23 13:40:12 +0000 |
commit | be9de111a5f9ba0e9716851b30f3b79be370a102 (patch) | |
tree | 4231466495d92f26db734c3d9f2d32438c8293d9 /includes/shell-tools.c | |
parent | 43a2e4a26175b9dbf29e39b97f7d032ef00f9993 (diff) | |
download | haskell-be9de111a5f9ba0e9716851b30f3b79be370a102.tar.gz |
Attach the INLINE Activation pragma to any automatically-generated specialisations
Another idea suggested by Roman, happily involving a one-line change. Here's
the new Note in Specialise:
Note [Auto-specialisation and RULES]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Consider:
g :: Num a => a -> a
g = ...
f :: (Int -> Int) -> Int
f w = ...
{-# RULE f g = 0 #-}
Suppose that auto-specialisation makes a specialised version of
g::Int->Int That version won't appear in the LHS of the RULE for f.
So if the specialisation rule fires too early, the rule for f may
never fire.
It might be possible to add new rules, to "complete" the rewrite system.
Thus when adding
RULE forall d. g Int d = g_spec
also add
RULE f g_spec = 0
But that's a bit complicated. For now we ask the programmer's help,
by *copying the INLINE activation pragma* to the auto-specialised rule.
So if g says {-# NOINLINE[2] g #-}, then the auto-spec rule will also
not be active until phase 2.
Diffstat (limited to 'includes/shell-tools.c')
0 files changed, 0 insertions, 0 deletions