What should and should not be marked has_side_effects?

[Carter Schonwald]

I know that in the case of the prefetch operations they need to be treated
like writes so that other operations don't get reordered before / after
them.

For Mvars, concurrency probably comes into play.  Or at least, before we
did a readMvar primop it was made out of a take and put, so even through
the read prim doesn't write and doesn't block other readers, we still want
to treat it's ordering as through it has a write like side effect (Edward
yang can probably better opine than I on that one )





On Fri, Mar 10, 2017 at 5:17 PM David Feuer <david at well-typed.com> wrote:

> Note [PrimOp can_fail and has_side_effects] in prelude/PrimOp.hs says
>
> > A primop "has_side_effects" if it has some *write* effect, visible
> > elsewhere
> >
> >     - writing to the world (I/O)
> >     - writing to a mutable data structure (writeIORef)
> >     - throwing a synchronous Haskell exception
> >
> > [...]
> >
> >  * NB3: *Read* effects (like reading an IORef) don't count here,
> >
> >    because it doesn't matter if we don't do them, or do them more than
> >    once.  *Sequencing* is maintained by the data dependency of the state
> >    token.
>
> But this does not actually seem to match what goes on in primops.txt.pp.
> The
> following, among many other seemingly read-only operations, have
> has_side_effects = True:
>
> readMutVar# (the very example cited!), readArray#, unsafeFreezeArray#,
> unsafeThawArray#, tryReadMVar#, deRefWeak#
>
> So what's the correct story? Do we want to change the note, or change the
> reality? The reason I happen to be looking at this is that I think the
> current
> arrangement allows us to define unsafeInterleaveIO in a particularly simple
> fashion:
>
> unsafeInterleaveIO = pure . unsafePerformIO
>
> but that's only safe as long as the interleaved IO won't float out and get
> performed before it's forced by normal IO.
>
> But the unsafeInterleaveIO story seems much less important, in the grand
> scheme of things, than making everything else run fast. If indeed it's
> otherwise safe to mark these read-only ops has_side_effects=False, then I
> imagine we probably should do that.
>
> David Feuer
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170311/808aca85/attachment.html>