This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] RFC: Never gimplify ASM_EXPRs
- From: <tm_gccmail at mail dot kloo dot net>
- To: Linus Torvalds <torvalds at transmeta dot com>
- Cc: Richard Henderson <rth at redhat dot com>,Jason Merrill <jason at redhat dot com>,Zack Weinberg <zack at codesourcery dot com>,Diego Novillo <dnovillo at redhat dot com>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 6 Jun 2003 12:46:54 -0700 (PDT)
- Subject: Re: [tree-ssa] RFC: Never gimplify ASM_EXPRs
On Fri, 6 Jun 2003, Linus Torvalds wrote:
>
> 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.
>
> That too. It's not a hugely common problem, but it does occur, and it
> would be good to have a separate "read memory" clobber for those things
> that want memory to be stable, but don't need the compiler to reload all
> memory objects afterwards. Something like
>
> #define wmb() \
> asm("sfence": : :"readmem")
>
> might be a good thing to have one day. But I don't worry too much about
> it.
>
> Linus
When I was at Sega, we had problems with the inline assembly as well in a
different way. Basically, they're not fine-grained enough.
We really needed the ability to specify which objects would be clobbered
by the inline assembly to miminize the memory thrashing.
Something like:
float in_array[256], out_array[256], other_stuff[256];
...
asm("..." : : : "r:in_array" "rw:out_array");
...so we can specify that in_array will be read and out_array will be both
read and written by the inline assembly, and other_stuff will not be
modified.
Toshi