let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?

[Carter Schonwald]

when i run
./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint -S  -fforce-recomp
-ddump-simpl -ddump-to-file –dverbose-core2core –ddump-occur-anal
–ddump-inlinings
i get
target ‘–dverbose-core2core’ is not a module name or a source file

what am I doing wrong in this CLI invocation?

On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  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:carter.schonwald at gmail.com]
> *Sent:* 24 November 2014 00:54
> *To:* Edward Kmett
> *Cc:* ghc-devs at haskell.org; 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 <
> carter.schonwald at gmail.com> 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 <
> carter.schonwald at gmail.com> 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 <ekmett at gmail.com> 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 <
> carter.schonwald at gmail.com> 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
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141124/3d81b768/attachment-0001.html>