#8256: adding locality levels to prefetch# and friends -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8252 ,#8107 -------------------------------------+------------------------------------ Comment (by thoughtpolice): This patch looks to be mostly in pretty good shape, so I think it can go in with a little more work. In regards to point 1 from @tibbe, IMO it's perfectly reasonable to just have the code generator emit an empty piece of code for the other backends. prefetch can't change the semantics, only the performance - so simply emitting a no-op in the other backends is a perfectly legitimate thing to do, and easy. I'm not aware of any hardware we support where prefetching isn't strictly an optimization. As for names? I don't really mind that much. The usage of the 0-3 constants for locality argument comes from GCC, where `__builtin_prefetch` has a locality argument ranging from 0 to 3. There is no real mnemonic here: 3 means it should be left in cache if possible as it has high locality, 0 means it can be evicted after access (low locality,) and 1-2 are just "somewhere inbetween 0 and 3." I imagine LLVM inherited this convention from GCC, and I'm not sure what else we could sensibly call them. That said, we do need a test, and the primops need docs. There are also a lot of typos and random comments laying around which would be nice to get cleaned up (mostly punctuation, stuff like that.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8256#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler