Re: [GHC] #2163: GHC makes thunks for Integers we are strict in
On Tue, Mar 18, 2008 at 04:12:35PM -0000, GHC wrote:
W.f = \ (x_a5h :: GHC.Num.Integer) -> let { x'_sa7 [ALWAYS Just S] :: GHC.Num.Integer [Str: DmdType] x'_sa7 = GHC.Num.plusInteger x_a5h W.lvl } in GHC.Num.timesInteger x'_sa7 x'_sa7
`let` can be strict in Core - it doesn't always indicate a thunk.
Aha! I knew that let was strict for types like Int#, but didn't realise that it could be for "normal" types too. What is it in the above let that shows that it will be evaluated strictly? The "Just S"? Also, what is the advantage to having strictly evaluated let's, both for unboxed and normal types? Presumably it helps with some optimisation - perhaps let-bound things might be inlined, whereas case'd things aren't, which reduces the number of cases the optimiser needs to consider, or something?
(don't worry, this often catches me out too. Perhaps a strict let should be indicated more explicitly in `-ddump-simpl`).
I'd certainly find it useful if it was clearer. Thanks Ian
On Wed, Mar 19, 2008 at 05:31:08PM +0000, Ian Lynagh wrote:
On Tue, Mar 18, 2008 at 04:12:35PM -0000, GHC wrote:
(don't worry, this often catches me out too. Perhaps a strict let should be indicated more explicitly in `-ddump-simpl`).
I'd certainly find it useful if it was clearer.
In fact, simpl hides more than I'd realised. With these definitions: f :: Integer -> Integer -> Integer -> Integer f x y z | y == 1 = x * z | otherwise = f (x * x) y (z * z) g :: Integer -> Integer -> Integer -> Integer g x y z | y == 1 = x | otherwise = g (x * x) y (z * z) simpl shows B.f (GHC.Num.timesInteger x_a5B x_a5B) y_a5D (GHC.Num.timesInteger z_a5F z_a5F); and B.g (GHC.Num.timesInteger x_a74 x_a74) y_a76 (GHC.Num.timesInteger z_a78 z_a78); for the recursive calls, although in the STG you can see that the multiplication of z is done strictly in f but not g (which is correct, as g is not strict in z). So perhaps the solution is just that I should look at the STG rather than the simpl when I want to see what's going on. Thanks Ian
igloo:
On Wed, Mar 19, 2008 at 05:31:08PM +0000, Ian Lynagh wrote:
On Tue, Mar 18, 2008 at 04:12:35PM -0000, GHC wrote:
(don't worry, this often catches me out too. Perhaps a strict let should be indicated more explicitly in `-ddump-simpl`).
I'd certainly find it useful if it was clearer.
In fact, simpl hides more than I'd realised. With these definitions:
f :: Integer -> Integer -> Integer -> Integer f x y z | y == 1 = x * z | otherwise = f (x * x) y (z * z)
g :: Integer -> Integer -> Integer -> Integer g x y z | y == 1 = x | otherwise = g (x * x) y (z * z)
simpl shows
B.f (GHC.Num.timesInteger x_a5B x_a5B) y_a5D (GHC.Num.timesInteger z_a5F z_a5F);
and
B.g (GHC.Num.timesInteger x_a74 x_a74) y_a76 (GHC.Num.timesInteger z_a78 z_a78);
for the recursive calls, although in the STG you can see that the multiplication of z is done strictly in f but not g (which is correct, as g is not strict in z).
So perhaps the solution is just that I should look at the STG rather than the simpl when I want to see what's going on.
Thanks
We really need an official and blessed view of the optimised core, with full, relevant information, in human readable form. Just simplifiying the obvious qualified names would be a start, and some simple alpha renaming. -- Don
participants (2)
-
Don Stewart -
Ian Lynagh