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.schonw...@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 < > 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