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

[Carter Schonwald]

huh, apparently i was mixing up '-' and some other similar dash character,
time to let my rebuild of ghc go through then try gain :)

On Mon, Nov 24, 2014 at 10:37 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> 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/bb3bb143/attachment.html>