Can you please clarify the meaning of:
llvm.memory.barrier(i1 false, i1 false, i1 false, i1 false, i1 false)
Does it behave as:
__asm__ __volatile__ ("":::"memory");
Note: for gcc, this empty inline assembly behaves as a compiler
barrier which prevents optimizations across it, but it does not ensure
anything on CPU reordering ("volatile" prevents it from being
reordered *by the compiler* and "memory" in the clobber list prevents
caching memory values in registers).
I'm not totally sure this is good practice, but this "compiler
only"
barrier is used in low level code (drivers, threading libraries and
the linux kernel for instance) to prevent loops from being optimized
away in spinlocks, but also sometimes to force reloading values from
memory.
A strongly related question:
%result1 = load i32* %ptr
call void @llvm.memory.barrier(i1 true, i1 false, i1 false, i1 false, i1 false)
%result2 = load i32* %ptr
Can the code above be optimized (fusion of %result1,2) given an
architecture in which that memory barrier is not needed ?
The LLVM Language Reference states that, in architectures that do not
need some types of barrier, these become "noops" and, as far as I
know, nothing can be assumed about reordering and optimization of
noops.
All kinds of memory barrier should imply a compiler barrier in the
sense that I mentioned above, or at least this seems more logical to
me.
Thanks,
-- Giovanni
