3 ms·

Ok, your first paragraph seems to indicate you're talking about compile-time behavior, but don't believe that optimizations can be disabled in llvm to the same

Ok, your first paragraph seems to indicate you're talking about compile-time behavior, but don't believe that optimizations can be disabled in llvm to the same extent as in gcc, and maybe don't believe that clang can be used for fully reproducible builds. Your second paragraph does not appear to make any sense on its own or in the context of the rest of your comment. "the cooked performance of llvm" looks like a translation error. Nothing you're talking about has any relevance to a link about CUDA. Repeating the assertion that using gcc with optimizations disabled is sometimes desirable does not help explain why it is desirable, nor why equivalent results cannot be achieved using llvm. If you actually understand what you're talking about, it sounds like there might be an opportunity for an interesting and enlightening discussion about the specifics of compiler internals. But instead you again veer toward the vague insults and totally off-topic. Please don't do that.

Joel_Mckay 2y ago
The metastability in clock domains is a complex subject (it is a named problem with a finite number of solutions), and you were warned people have difficulty understanding why it is a challenge. A toy example: 1. set flag foo=1 2. check flag bar=1 3. set flag foo=0 4. check flag bar=0 These events happen in a sub-optimal repeatable order on non-optimized gcc C, and with precise predictable/verifiable op timing. We will assume interrupts are disabled in critical sections, and register states are repeatable prior to execution. Yet, the same "bar" may have undefined behavior in llvm given the flag states look unrelated to the compiler, order/operations may not be preserved when abstracted, and linear-timing is now a compile-time packed op specific random ordered implementation. Thus, event times may happen before the parallel state has actually occurred. Perhaps I am not the right person to explain this subject, but would recommend looking at the zynq FPGA Linux kernel example DMA module structure for more details. It should demonstrate how to coordinate parallel things better using 1 or more of the known metastability issue workarounds, and the constraints of state propagation across complex logic fabric. In some use-cases repeatability is more important than performance/assumptions-of-safety. There is a clear difference between Application space and RT space. This is as far as I can guide folks on the subject, and if one has never encountered these issues... than don't worry about it... Best of luck, =3
- wtallis 2y ago
  It sounds to me like you're claiming gcc is superior on the basis of incorrect code that doesn't make proper use of the volatile keyword and explicit memory barriers.
  - Joel_Mckay 2y ago
    "volatile" will not help with this class of problem. Don't worry about it... if your primary use-case is in Application space, than it won't matter most of the time. =3
    - wtallis 2y ago
      > "volatile" will not help with this class of problem. Well, it's a good thing my comment had more words past that one. "volatile" is only part of the solution, and when more than one MMIO location is in play (as in your example), "volatile" on its own is insufficient but proper use of "volatile" plus explicit memory barriers will enforce correct ordering of loads and stores.

Joel_Mckay 2y ago

The metastability in clock domains is a complex subject (it is a named problem with a finite number of solutions), and you were warned people have difficulty understanding why it is a challenge. A toy example: 1. set flag foo=1 2. check flag bar=1 3. set flag foo=0 4. check flag bar=0 These events happen in a sub-optimal repeatable order on non-optimized gcc C, and with precise predictable/verifiable op timing. We will assume interrupts are disabled in critical sections, and register states are repeatable prior to execution. Yet, the same "bar" may have undefined behavior in llvm given the flag states look unrelated to the compiler, order/operations may not be preserved when abstracted, and linear-timing is now a compile-time packed op specific random ordered implementation. Thus, event times may happen before the parallel state has actually occurred. Perhaps I am not the right person to explain this subject, but would recommend looking at the zynq FPGA Linux kernel example DMA module structure for more details. It should demonstrate how to coordinate parallel things better using 1 or more of the known metastability issue workarounds, and the constraints of state propagation across complex logic fabric. In some use-cases repeatability is more important than performance/assumptions-of-safety. There is a clear difference between Application space and RT space. This is as far as I can guide folks on the subject, and if one has never encountered these issues... than don't worry about it... Best of luck, =3

wtallis 2y ago
It sounds to me like you're claiming gcc is superior on the basis of incorrect code that doesn't make proper use of the volatile keyword and explicit memory barriers.
- Joel_Mckay 2y ago
  "volatile" will not help with this class of problem. Don't worry about it... if your primary use-case is in Application space, than it won't matter most of the time. =3
  - wtallis 2y ago
    > "volatile" will not help with this class of problem. Well, it's a good thing my comment had more words past that one. "volatile" is only part of the solution, and when more than one MMIO location is in play (as in your example), "volatile" on its own is insufficient but proper use of "volatile" plus explicit memory barriers will enforce correct ordering of loads and stores.