Re: basic asm and memory clobbers - Proposed solution
On 12/14/2015 09:10 AM, Segher Boessenkool wrote:
That, and adding a memory clobber degrades performance for a lot of
existing basic asm that does not expect the clobber, e.g. asm(""),
asm("#"), asm("nop"), ...
I wonder about this. People keep bringing up "a lot of existing basic
asm" in general, but are there any known examples in real software?
Bernd
AW: basic asm and memory clobbers - Proposed solution
Hi,
On 12/15/2015 13:52, Bernd Schmidt wrote:
>
> On 12/14/2015 09:10 AM, Segher Boessenkool wrote:
> > That, and adding a memory clobber degrades performance for a lot of
> > existing basic asm that does not expect the clobber, e.g. asm(""),
> > asm("#"), asm("nop"), ...
>
> I wonder about this. People keep bringing up "a lot of existing basic
> asm" in general, but are there any known examples in real software?
Yes, there are, I see a few in our own tree:
./libatomic/config/x86/fenv.c: asm volatile ("fwait");
./libcilkrts/runtime/config/x86/os-fence.h:# define __cilkrts_fence() __asm__
volatile ("lock addl $0,(%rsp)")
./libsanitizer/sanitizer_common/sanitizer_atomic_clang_x86.h:__asm__
__volatile__("pause");
./libgfortran/config/fpu-387.h: __asm__ __volatile__ ("fwait");
./libgcc/unwind-dw2.c: asm ("");
./libgcc/config/i386/sfp-exceptions.c: asm volatile ("fwait");
./libgcc/config/lm32/_udivsi3.c: __asm__ __volatile__ ("mv ea, ra");
./boehm-gc/include/private/gc_locks.h:#define GC_clear(addr) { asm("mb");
*(volatile unsigned *)addr = 0; }
!! this one really needs memory clobber !!
./boehm-gc/include/private/gc_locks.h:# define GC_memory_barrier() asm("mb")
./boehm-gc/mach_dep.c:asm("pushl r11"); asm("calls $1,_GC_push_one");
Bernd.
Re: basic asm and memory clobbers - Proposed solution
> On Dec 15, 2015, at 7:52 AM, Bernd Schmidt wrote:
>
> On 12/14/2015 09:10 AM, Segher Boessenkool wrote:
>> That, and adding a memory clobber degrades performance for a lot of
>> existing basic asm that does not expect the clobber, e.g. asm(""),
>> asm("#"), asm("nop"), ...
>
> I wonder about this. People keep bringing up "a lot of existing basic asm" in
> general, but are there any known examples in real software?
In the codebase for the product I work on, I see about 200 of them. Many of
those are the likes of asm("sync") for MIPS, which definitely wants to be
treated as if it were asm ("sync" : : : "memory").
That's not counting the hundreds I see in gdb/stubs -- those are "outside a
function" flavor.
paul
Re: basic asm and memory clobbers - Proposed solution
On 12/15/2015 01:42 PM, paul_kon...@dell.com wrote:
On Dec 15, 2015, at 7:52 AM, Bernd Schmidt
wrote:
On 12/14/2015 09:10 AM, Segher Boessenkool wrote:
That, and adding a memory clobber degrades performance for a lot
of existing basic asm that does not expect the clobber, e.g.
asm(""), asm("#"), asm("nop"), ...
I wonder about this. People keep bringing up "a lot of existing
basic asm" in general, but are there any known examples in real
software?
In the codebase for the product I work on, I see about 200 of them.
Many of those are the likes of asm("sync") for MIPS, which definitely
wants to be treated as if it were asm ("sync" : : : "memory").
Precisely. And it's these kind that are subject to "oh, surprise,
gcc-new does some new optimization of loads/stores and your previously
working code now fails miserably". Oh, and good luck finding it, these
kinds of things are notoriously tough to track down.
And that is bad on so many levels.
The only sensible way forward is to treat them like memory barriers.
That's what is expected and that is what we should be doing. The fact
that we haven't done it is simply a bug.
The fact that someone might lose the ability to do memory optimizations
across asm ("") or asm ("#") or asm ("nop") is not reason to keep the
status quo.
Sadly, I'm putting most of this discussion into my gcc-7 queue anyway.
Jeff
Re: basic asm and memory clobbers - Proposed solution
On 12/14/2015 1:53 AM, Andrew Haley wrote: > This just seems like another argument for deprecating basic asm and pushing people to extended. Yes. I am not arguing against deprecation. We should do that. You know, there are several people who seem to generally support this direction. Not enough to call it a consensus, but perhaps the beginning of one: - Andrew Haley - David Wohlferd - Richard Henderson - Segher Boessenkool - Bernd Schmidt Anyone else want to add their name here? Maybe it's the implementation details that have other people concerned. My thought is that for v6 we change the docs to say something like: - Unlike top level, using basic asm within a function is deprecated. No new code should use this feature, but should use extended asm instead. Existing code should begin replacing such usage. Instances of affected code can be found using -Wonly-top-basic-asm. For help making this conversion, see "How to convert Basic asm to Extended asm." - With this, we only need to add the warning as a non-default. This will (hopefully) stop new users from using this, and can begin the work of removing it from existing code. The problem with that approach is that (I'm told) some people don't read the docs. Imagine that. Such being the case, they won't even know this is happening. That's why I think that in the next phase 1 (v7?), we should change the warning to 'on' by default (or maybe as part of -Wall?). People will still be able to override it with no-, but at least it will raise awareness and chase more of it out of people's code. What about the final step of actually removing support for basic asm in a function as some people propose? Should we really do this? If so, when? That's a more difficult question. If we make the warning a default in v7, then it would be *at least* v8 before this should be considered. Trying to make any plan that far ahead seems... optimistic. Perhaps by then we'll have more feedback upon which to make a decision. We *could* be more aggressive and start right off with making the warning 'on' by default. But to give people the best chance to prepare, perhaps starting with the non-default is best. Even if we don't all agree about _removing_ "basic asm in a function," can we find consensus that having less of it is a good thing? Because this approach gets us that. dw
gcc-5-20151215 is now available
Snapshot gcc-5-20151215 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20151215/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 231665 You'll find: gcc-5-20151215.tar.bz2 Complete GCC MD5=159a89891f879f3dac5e03deffde564f SHA1=164b589695dd1f962405741008f66e50e76c199c Diffs from 5-20151208 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: basic asm and memory clobbers - Proposed solution
On Tue, 15 Dec 2015, David Wohlferd wrote: > Unlike top level, using basic asm within a function is deprecated. No new code > should use this feature, but should use extended asm instead. Existing code > should begin replacing such usage. Instances of affected code can be found > using -Wonly-top-basic-asm. For help making this conversion, see "How to > convert Basic asm to Extended asm." I think the typical use of basic asm is: you want to manipulate I/O registers or other such state unknown to the compiler (not any registers the compiler might use itself), and you want to do it in a way that is maximally compatible with as many compilers as possible (hence limiting yourself to the syntax subset that's in the C++ standard, for example). Compatibility with a wide range of other compilers is the critical thing here; this is not a GCC-invented feature, and considerations for deprecating an externally defined feature are completely different from considerations for GCC-invented features. Do you have evidence that it is now unusual for compilers to support basic asm without supporting GCC-compatible extended asm, or that other compiler providers generally consider basic asm deprecated? -- Joseph S. Myers jos...@codesourcery.com
Re: basic asm and memory clobbers - Proposed solution
> On Dec 15, 2015, at 5:22 PM, David Wohlferd wrote: > > On 12/14/2015 1:53 AM, Andrew Haley wrote: >> > This just seems like another argument for deprecating basic asm and >> > pushing people to extended. >> Yes. I am not arguing against deprecation. We should do that. > > You know, there are several people who seem to generally support this > direction. Not enough to call it a consensus, but perhaps the beginning of > one: > > - Andrew Haley > - David Wohlferd > - Richard Henderson > - Segher Boessenkool > - Bernd Schmidt > > Anyone else want to add their name here? No, but I want to speak in opposition. "Deprecate" means two things: warn now, remove later. For reasons stated by others, I object to "remove later". So "warn now, remove never" I would support, but not "deprecate". paul
