let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?
Carter Schonwald
carter.schonwald at gmail.com
Tue Nov 25 17:36:26 UTC 2014
i'm doing a bit of benchmarking today, and it may very well be that youre
absolutely correct about all of this in practice, at least the way things
are trending.
On Tue, Nov 25, 2014 at 1:47 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:
> ok attached is the log of
> ./inplace/bin/ghc-stage2 codetester.hs -O2 -dcore-lint -fforce-recomp
> -ddump-simpl -ddump-to-file -dverbose-core2core -ddump-occur-anal
> -ddump-inlinings > output ^&1
>
>
> the relevant snippet is bellow.
>
> It looks like the Float-Out transformation is what tripping it.
>
>
> That said, reading through what the semantics are implied by
> has_side_effects = True, the prefetch* family of operations ARE side
> effectful with respect the fact that they DO modify the CPU cache in a way
> that changes what memory locations are in various levels of CPU cache, so
> despite seeming read-like, they are modifying the state of the system, just
> in a way that is ONLY visible wrt the performance characteristics/runtime
> of the resulting program.
>
> specifically, Duplication, Floating out, and Specultive evaluation all
> change *when* the prefetch runs and changes the CPU state, and Discard
> means this "mutation" of the CPU cache state would not happen.
>
> if prefetch was pure semantically (ie equiv to a -> () ) , they'd just be
> no op, they're exclusively a tool for performance engineering, and
> accordingly when and where they appear in code matters!
>
> i'm more than happy to write out a more detailed version of this
> explanation somewhere if you like.
>
> -Carter
>
> """"
>
> *** Core Linted result of Simplifier:
> *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
> *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True,
> OverSatApps = True}):
> *** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
> Consts = True,
> OverSatApps = True}) ***
> <no location info>: Warning:
> In the expression: prefetchValue2#
> @ [Char]
> @ RealWorld
> lvl_s3Oi
> (prefetchValue1#
> @ Int
> @ RealWorld
> lvl_s3Oj
> (prefetchAddr3# @ RealWorld ds1_a3zg 0
> ds_a3zf))
> This argument does not satisfy the let/app invariant:
> prefetchValue1#
> @ Int
> @ RealWorld
> lvl_s3Oj
>
>
> """
>
>
>
> On Mon, Nov 24, 2014 at 10:43 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> 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/20141125/fce97ee4/attachment-0001.html>
More information about the ghc-devs
mailing list