[riot-notifications] [RIOT-OS/RIOT] sys: Added simple memory barrier API (#11438)

Marian Buschsieweke notifications at github.com
Thu Apr 25 12:42:00 CEST 2019


maribu commented on this pull request.



> + * uint16_t measure_time(void) {
+ *     uint16_t pre = TIMER;
+ *     do_computing();
+ *     uint16_t post = TIMER;
+ *     return pre - post;
+ * }
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * In the above example the compiler will now dutifully generate code to access
+ * the timer register two times. The compiler will also not reorder any
+ * `volatile` memory access in regard to any other `volatile` memory access.
+ * But some compilers will reorder non-`volatile` accesses across `volatile`
+ * memory accesses. If the implementation of `do_computing()` is visible to the
+ * compiler, the compiler may conclude that do_computing() could be moved
+ * above the first or below the second access to `TIMER`, which will render the
+ * benchmark meaningless. (**Beware:** Even if `do_something()` is an external

> In `test()`, the compiler is forced to emit a re-read of `x` because it does not know if `f()` modified it.

The call to `f()` behaves like a compiler barrier as long as the compiler cannot access the implementation of `f()`. With LTO this might no longer be the case (depending on where `f()` is implemented). But even if `f()` is implemented in a system library, we should not take it for granted to be a compiler barrier for all eternity: When LTO becomes more and more popular, maybe we get LTO-enabled static linking against system libraries (that is, system libraries are not stored in machine code but rather in the internal representation of the compiler to allow optimization over the whole program).

Therefore, I think we should not rely on calls to external function to behave like compiler barriers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/11438#discussion_r278494346
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190425/726e766e/attachment-0001.html>


More information about the notifications mailing list