Tried. Not working.
On Fri, Oct 8, 2021 at 10:35 PM Henrique de Moraes Holschuh <[email protected]> wrote: > > On 08/10/2021 05:39, 余生与君 wrote: > > And further investigation shows that a dummy function can also do this > > trick! > > When one wants any sort of barrier (compiler optimization barrier, CPU > execution barrier, memory barriers, etc) that works (and is also > extremely likely to remain working in the future) for both GCC and > CLANG, it is usually a good idea to take a look at what the linux kernel > is using. > > > --8<-- from include/linux/compiler.h (latest linux kernel source) > > /* Optimization barrier */ > #ifndef barrier > /* The "volatile" is due to gcc bugs */ > # define barrier() __asm__ __volatile__("": : :"memory") > #endif > > #ifndef barrier_data > /* > * This version is i.e. to prevent dead stores elimination on @ptr > * where gcc and llvm may behave differently when otherwise using > * normal barrier(): while gcc behavior gets along with a normal > * barrier(), llvm needs an explicit input variable to be assumed > * clobbered. The issue is as follows: while the inline asm might > * access any memory it wants, the compiler could have fit all of > * @ptr into memory registers instead, and since @ptr never escaped > * from that, it proved that the inline asm wasn't touching any of > * it. This version works well with both compilers, i.e. we're telling > * the compiler that the inline asm absolutely may see the contents > * of @ptr. See also: https://llvm.org/bugs/show_bug.cgi?id=15495 > */ > # define barrier_data(ptr) __asm__ __volatile__("": :"r"(ptr) :"memory") > #endif > > --8<-- > > -- > Henrique de Moraes Holschuh _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
