(not sure if this is a bug or a feature request, or a task, or a dialogue, filing as a bug for now)

a number of compiler intrinsics that GHC has started to support (prefetch) and will come to support (concurrent memory operations a la #7883 (closed)), require certain arguments to be statically fixed at compile time

primop PrefetchAddrOp "prefetchAddr#" GenPrimOp
   Addr# -> Int# -> Addr#
   with llvm_only = True

consider the specification on the llvm side for prefetch

http://llvm.org/docs/LangRef.html\#llvm-prefetch-intrinsic

Syntax:¶

declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>, i32 <cache type>)
Overview:

The ‘llvm.prefetch‘ intrinsic is a hint to the code generator to insert a prefetch instruction if supported; otherwise, it is a noop. Prefetches have no effect on the behavior of the program but can change its performance characteristics.
Arguments:

address is the address to be prefetched, rw is the specifier determining if the fetch should be for a read (0) or write (1), and locality is a temporal locality specifier ranging from (0) - no locality, to (3) - extremely local keep in cache. The cache type specifies whether the prefetch is performed on the data (1) or instruction (0) cache. The rw, locality and cache type arguments must be constant integers.

the punch line is that we're starting add primops that REALLY require certain arguments to be compile time constants to work correctly, otherwise there will by definition be compiler errors after the c-- phase when operations are passed along to the llvm backend and friends. (for the atomicity ops, i'll be looking into adding them to the native code gen, but the point being it will likely trigger an error at code gen time).

a strawman approach would look like adding a type ReallyActuallyConstant :: * or unliftedtype -> * unliftedtype roughly, then prefetch could have the type

primop PrefetchAddrOp "prefetchAddr#" GenPrimOp
   Addr# ->ReallyActuallyConstant Int# -> Addr#
   with llvm_only = True

a way of emulating something like this functionality now, would be some template haskell that lets you lift a compile time constant of type t into the type ReallyActuallyConstant t, and is the only way to build a value of that type "ReallyActuallyConstant t". That said, that approach seems like a bad way of providing type safetype for making sure primops actually compile!

Point being, some sort of way of nicely enforcing that a value needs to be available at compile time, that doesn't require doing abusing template haskell, is the idea i'm pointing at. Might also be useful for other things, but for now, i'm merely remarking on an invariant these primops have