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 <simo...@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.schonw...@gmail.com] > *Sent:* 24 November 2014 00:54 > *To:* Edward Kmett > *Cc:* ghc-devs@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.schonw...@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.schonw...@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 <ekm...@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.schonw...@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@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > > > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs