[PATCH] [RFC] __builtin___clear_cache support in LLVM
daniel.sanders at imgtec.com
Tue Mar 18 04:45:36 PDT 2014
> 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.
The main use-case that would ideally have additional kinds of cache flushes are DMA transfers (and similar things like device drivers, or communication between two processors in an SoC via shared memory). For a write-back cache, there are three kinds of cache flush that are useful to this case:
* Write dirty lines to memory. This is mainly useful for outbound DMA transfers where it is useful to keep any cached data in the cache.
* Invalidate lines in the cache. This is mainly useful for inbound DMA transfers so that you don't cause unnecessary memory traffic writing useless data back to memory.
* Both write-back and invalidate. Useful for outbound DMA transfers where the data will no longer be used by the source.
The intended recipient of the data can matter too. For example, suppose an L2 cache is coherent for two processors under it, and there are two L1 caches (one for each processor) which are potentially incoherent with each other. To get data from one to the other, you'd ideally flush only the L1 caches. In other cases, such as writing to an external device, you'd need to flush both L1 and L2.
> Also, I'm not sure the user wants the compiler to second-guess their decisions to hammer the cache, as I believe these calls are not inserted lightly, but on execution errors after hours of debugging and internet searching. ;)
I strongly agree with this. Explicit cache flushes are generally a sign that the programmer has strayed (or is about to stray) outside the standard memory model for the system and is trying to repair the state. Given that the state of the system is in doubt, it's reasonable to say that the compilers opinion of the state is also in doubt. It therefore shouldn't try move or remove cache flushes.
More information about the llvm-commits