[PATCH] [RFC] __builtin___clear_cache support in LLVM

[JF Bastien]

  Great point by Tim, I can't think of anything right now, but there may be reasons to expose more than "clear cache in range" which really flushes D->I. I pinged a few folks, hope they'll chime in.


================
Comment at: include/llvm/IR/Intrinsics.td:515
@@ +514,3 @@
+def int_clear_cache : Intrinsic<[], [llvm_ptr_ty, llvm_ptr_ty],
+                                [IntrReadWriteArgMem], "llvm.clear_cache">;
+
----------------
Renato Golin wrote:
> JF Bastien wrote:
> > Maybe I'm being overly paranoid, but __clear_cache is sometimes used when something is mapped at multiple virtual addresses. IIUC having ReadWriteArgMem wouldn't be correct in these cases, even if the amount of memory accessed from the arguments is unspecified. I think specifying nothing would be better (equivalent to the non-existent ReadWriteMem?).
> __clear_cache can use or not the arguments provided, it can invalidate different ranges of cache, read from memory and, who knows, even write to memory. Since the behaviour is completely unspecified, I tried to use the most conservative model, ie. "we break stuff". If specifying nothing would achieve that, I'm fine with it.
> 
> Most of the cases, though, nothing will be there to move around loads and stores, so that will only be relevant on platforms that do implement the cleaning.
Documentation says: If no property is set, the worst case is assumed (it may read and write any memory it can get access to and it may have other side effects).

So IIUC specifying nothing seems correct, since otherwise only the parameters+offset are assumed accessible for read/write.

================
Comment at: include/llvm/Target/TargetLowering.h:2114
@@ +2113,3 @@
+    return 0;
+  }
+
----------------
Renato Golin wrote:
> JF Bastien wrote:
> > This seems like a pretty bad silent failure waiting to occur for targets other than x86/ARM/MIPS: implementor won't know that they have to add this. Making the function pure virtual would force everyone to return 0 when, like x86, there's nothing to do, and in all other cases they'd need to do the right thing for their platform. It's either break everyone's build loudly, or everyone's runtime silently.
> > 
> > It would also help understanding if the comment said that return 0 means "call nothing" (unless I misunderstood and that's not what it means).
> good point, I'll change that to llvm_unreachable or something of the sort.
Pure virtual function is better, since it forces implementation. llvm_unreachable makes it a runtime error, albeit a better one than silently dropping the call!


http://llvm-reviews.chandlerc.com/D3084