RFC: are duplications / float outs acceptable for prefetches or not?

Carter Schonwald carter.schonwald at gmail.com
Mon Sep 16 05:35:17 UTC 2013


just for reference, the  current ops are


primop PrefetchByteArrayOp2 "prefetchByteArray2#" GenPrimOp
   ByteArray# -> Int# -> ByteArray#
   with llvm_only = True

primop PrefetchMutableByteArrayOp2 "prefetchMutableByteArray2#" GenPrimOp
   MutableByteArray# s -> Int# -> State# s -> State# s
   with has_side_effects = True
        llvm_only = True

primop PrefetchAddrOp2 "prefetchAddr2#" GenPrimOp
   Addr# -> Int# -> Addr#
   with llvm_only = True

one of the things my patch (for 7.8) will do is add preliminary native code
gen support for prefetch, admittedly in the form of Nops. (later work will
fix that to be a bit more actionable)


any opinions that help us suss this out would be appreciated




On Mon, Sep 16, 2013 at 1:08 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Hey all,
> I"ve been doing some work to finish up my prefetch patch that  I hope to
> land in 7.8, and one design matter thats come up is what the optimization
> semantics should be!
>
> is it appropriate to duplicate prefetches? (probably yes)
> is it appropriate to float OUT prefetched? (probably not?)
>
> operations that are dupable which shouldn't float out are marked with the
> can_fail= true
> property,
> operations which cannot be safely floated out and can't be duped are
> marked as having side effects.
>
> on the GHC irc channel, Duncan was patient enough to walk my through
> understanding this, and this makes me lean towards the conclusion that
> duplication is ok, but floating out isnt. Thus all the prefetch ops (pure
> or not) should have the attribute "can fail", rather than no attribut or
> "has effects".
>
> this is exploiting that "can fail"  really just means "don't float out".
>
> thoughts and counter points?
>
> thanks
>
> -Carter
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130916/ec359626/attachment.htm>


More information about the ghc-devs mailing list