This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] RFC: Never gimplify ASM_EXPRs


>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

 Linus> On Fri, 6 Jun 2003, Richard Henderson wrote:
 >> The struct thing I always placed in a different class of
 >> workaround.  You had a read from a "large" object in memory.  At
 >> least for some version of the compiler, this may have been
 >> interpreted as a read from ALL memory, resulting in a memory write
 >> barrier that didn't affect cached reads.  I.e. possibly a bit
 >> better optimization-wise than the normal "memory" clobber.

 Linus> That too. It's not a hugely common problem, but it does occur,
 Linus> and it would be good to have a separate "read memory" clobber
 Linus> for those things that want memory to be stable, but don't need
 Linus> the compiler to reload all memory objects
 Linus> afterwards. Something like

 Linus> #define wmb() \ asm("sfence": : :"readmem")

 Linus> might be a good thing to have one day. But I don't worry too
 Linus> much about it.

I found that an "old style" asm appears to have that effect.  In fact,
asm("") produces a "compiler memory barrier" effect.  And I could
definitely use such a beast.  Unfortunately, I was warned not to count
on this property since it's accidental, not documented.

It would be good to have a documented way to do this; a "readmem"
clobber spec, or something like it, sounds like a good way.

	paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]