On 2014/04/01 16:40:25, JF wrote:
On 2014/04/01 16:28:59, JF wrote:
> On 2014/04/01 16:19:36, Alexandre Rames wrote:
> > On 2014/04/01 16:08:09, JF wrote:
> > > I'm not sure I understand why "memory" is kept in some places and
removed
in
> > > others.
> > >
> > > lgtm otherwise.
> >
> > From http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html :
> >
> > If your assembler instructions access memory in an unpredictable
fashion,
add
> > 'memory' to the list of clobbered registers. This causes GCC to not
keep
> memory
> > values cached in registers across the assembler instruction and not
optimize
> > stores or loads to that memory. You also should add the volatile
keyword
if
> the
> > memory affected is not listed in the inputs or outputs of the asm, as
the
> > 'memory' clobber does not count as a side-effect of the asm.
> >
> > So memory is needed when we have barriers, but not when we
use 'simple'
> > load/store instructions.
>
> I see, you want to ensure no memory values are registerized across
> acquire/release?
>
> In that case I think "memory" should be kept in functions that have a
single
> barriers, and the barriers should probably be moved into the asm
statements,
> otherwise the compiler could technically move memory operations between
a
> barrier and the asm statement. e.g. Acquire_CompareAndSwap uses
> NoBarrier_CompareAndSwap followed by MemoryBarrier, and nothing
technically
> prevents memory operations to move around.
Yes! Forgot about that. I'll do a test to see what the compiler generates in
both cases.
Unless that's on purpose (i.e. you're telling the compiler to acquire or
release
at the time it finds most convenient, taking the barrier into account), in
which
case this should be documented.
https://codereview.chromium.org/220793002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
