Hi,
On Thu, 26 May 2011, Andrew Haley wrote:
> >>> +Generates the @code{pause} machine instruction.
> >>
> >> But that's missing the fact that it generates a compiler memory
> >> barrier, which is important. And if you think it's not a compiler
> >> memory barrier, please explain
> >>
> >> a. Why it's not a compiler memory barrier,
> >
> > It is not a compiler memory barrier because it is a builtin function call
> > which is never assumed to be a barrier for local automatic storage
> > that does not have its address taken.
>
> OK. How would you tell the difference between the kind of barrier
> that it is and a real compiler memory barrier?
First we have to determine if this builtin really does what its users
intend to use it for. I believe they _do_ want to use it also with
regards to auto variables (it includes also address-takens whose address
doesn't escape). A normal builtin call is not a barrier for operations on
such entities, hence it might very well be that the implementation of HJ
actually doesn't what he wanted.
I don't have a good word for what functions calls are in their barrierness
part of pre/post conditions. "global memory movement barrier" perhaps,
with an appropriate definition of global memory (which funnily include
address-taken escaped local storage, ugh).
> > To make it a compiler memory barrier you have to "expand" the
> > builtin already in the frontend and present the middle-end with
> > __asm__ ("...." : : : "memory"). That will serve as a compiler
> > memory barrier also covering local non-address taken storage
> > (global and practically most of address-taken local storage
> > is covered by a builtin function call already).
>
> Well, the fact that it's also a memory clobber has to be documented
> somehow. If the present documentation is to be changed, it should
> not be changed by deleting a vital piece of information.
It's not only about the docu. As implemented right now it's neither an
optimization barrier nor a memory clobber.
Ciao,
Michael.
