Carter
That smells wrong to me. These flags have a very carefully defined meaning; see
Note [PrimOp can_fail and has_side_effects]
in PrimOp.lhs
If you say it has side effects when it doesn’t, you’ll confuse your successor
reading the code in five years time.
Better to find out what is going on and why. Might you do that? What
transformation invalidates the let/app invariant? Make a small test case, use
–dverbose-core2core –ddump-occur-anal –ddump-inlinings. I would far rather
that than install a land-mine in the code.
Simon
From: Carter Schonwald [mailto:[email protected]]
Sent: 24 November 2014 00:54
To: Edward Kmett
Cc: [email protected]; Simon Peyton Jones; Joachim Breitner
Subject: Re: let app invariant failure, HALP Re: how to write a ghc primop that
acts on an unevaluated argument?
woot, solved it, at least in a way thats OK for now.
if I mark the prefetchValue operations as has_side_effects=True, the core lint
failure goes away! I'm not sure if thats the right semantics in the long term,
but it does give me a simple way to make sure it works safely for 7.10
pardon all the noise
-Carter
On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald
<[email protected]<mailto:[email protected]>> wrote:
ok, i'm getting a let/app invariant failure when i build my test case with O1
or O2 but not without
http://lpaste.net/114881
any help would be appreciated on how to address that
On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald
<[email protected]<mailto:[email protected]>> wrote:
yup, i have that!
wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
in the test suite!
in contrast
wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated") does
explode
shall I add a "should fail" test with the latter? (it doesn't seem worthwhile)
On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett
<[email protected]<mailto:[email protected]>> wrote:
Maybe test for laziness in the argument by just putting something in that goes
boom when forced, e.g. 'undefined'?
On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald
<[email protected]<mailto:[email protected]>> wrote:
Hey All,
as part of trying to get some fixups for how prefetch works into 7.10,
i'm adding a "prefetchValue" primop that prefetchs the memory location of a
lifted heap value
namely
several operations of the following form
primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
a -> State# s -> State# s
with strictness = { \ _arity -> mkClosedStrictSig [botDmd, topDmd] topRes }
I'd like some feedback on the strictness information design by someone who's
familiar with how that piece of GHC. the idea being that prefetchValue is lazy
in its polymorphic argument (it doesn't force it, it just does a prefetch on
the heap location, which may or may not be evaluated).
https://phabricator.haskell.org/D350
is the code in question. And i *believe* i'm testing for being lazy in that
argument correctly.
thoughts?
many thanks!
-Carter
_______________________________________________
ghc-devs mailing list
[email protected]<mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
