* basic asm and memory clobbers @ 2015-11-09 0:10 David Wohlferd 2015-11-09 9:32 ` Segher Boessenkool 0 siblings, 1 reply; 58+ messages in thread From: David Wohlferd @ 2015-11-09 0:10 UTC (permalink / raw) To: gcc; +Cc: rth, pinskia, Jeff Law, Sandra Loosemore [-- Attachment #1: Type: text/plain, Size: 645 bytes --] It seems like a doc update is what is needed to close PR24414 (Old-style asms don't clobber memory). I'm working on this now (phase 1) in the unlikely event that someone is inspired to make a code change here instead. Like Richard Henderson, I rather expected basic (or "old-style") asm to perform a memory clobber (it doesn't). This bug is now over a decade old, so presumably the question of how this is going to work is settled. IAC, the docs should reflect the current behavior. Based on this issue plus what I have learned since last updating this page, I'm proposing the attached patch. dw CCing the commenters from the bug. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 24414.patch --] [-- Type: text/x-patch; name="24414.patch", Size: 1211 bytes --] Index: extend.texi =================================================================== --- extend.texi (revision 229910) +++ extend.texi (working copy) @@ -7353,7 +7353,8 @@ @end itemize Safely accessing C data and calling functions from basic @code{asm} is more -complex than it may appear. To access C data, it is better to use extended +complex than it may appear. To access C data (including both local and +global register variables), use extended @code{asm}. Do not expect a sequence of @code{asm} statements to remain perfectly @@ -7376,6 +7377,12 @@ visibility of any symbols it references. This may result in GCC discarding those symbols as unreferenced. +Basic @code{asm} statements are not treated as though they used a "memory" +clobber, although they do implicitly perform a clobber of the flags +(@pxref{Clobbers}). Also, there is no implicit clobbering of registers, +so any registers changed must be restored to their original value before +exiting the @code{asm}. + The compiler copies the assembler instructions in a basic @code{asm} verbatim to the assembly language output file, without processing dialects or any of the @samp{%} operators that are available with ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-09 0:10 basic asm and memory clobbers David Wohlferd @ 2015-11-09 9:32 ` Segher Boessenkool 2015-11-16 1:23 ` David Wohlferd 0 siblings, 1 reply; 58+ messages in thread From: Segher Boessenkool @ 2015-11-09 9:32 UTC (permalink / raw) To: David Wohlferd; +Cc: gcc, rth, pinskia, Jeff Law, Sandra Loosemore On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote: > It seems like a doc update is what is needed to close PR24414 (Old-style > asms don't clobber memory). What is needed to close the bug is to make the compiler work properly. Whether that means clobbering memory or not, I don't much care -- with the status quo, if you want your asm to clobber memory you have to use extended asm; if basic asm is made to clobber memory, if you want your asm to *not* clobber memory you have to use extended asm (which you can with no operands by writing e.g. asm("bork" : ); ). So both behaviours are available whether we make a change or not. But changing things now will likely break user code. > Safely accessing C data and calling functions from basic @code{asm} is more > -complex than it may appear. To access C data, it is better to use extended > +complex than it may appear. To access C data (including both local and > +global register variables), use extended > @code{asm}. I don't think this makes things clearer. Register vars are described elsewhere already; if you really think it needs mentioning here, put it at the end (in its own sentence), don't break up this sentence. (dot space space). > +Basic @code{asm} statements are not treated as though they used a "memory" > +clobber, although they do implicitly perform a clobber of the flags > +(@pxref{Clobbers}). They do not clobber the flags. Observe: === void f(int a) { a = a >> 2; if (a <= 0) asm("OHAI"); if (a >= 0) asm("OHAI2"); } === Compiling this for powerpc gives (-m32, edited): f: srawi. 9,3,2 # this sets cr0 ble 0,.L5 # this uses cr0 .L2: OHAI2 blr .p2align 4,,15 .L5: OHAI bnelr 0 # this uses cr0 b .L2 which shows that CR0 (which is "cc") is live over the asm. So are all other condition regs. It is true for cc0 targets I guess, but there aren't many of those left. > Also, there is no implicit clobbering of registers, > +so any registers changed must be restored to their original value before > +exiting the @code{asm}. One of the important uses of asm is to set registers GCC does not know about, so you might want to phrase this differently. Segher ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-09 9:32 ` Segher Boessenkool @ 2015-11-16 1:23 ` David Wohlferd 2015-11-16 21:29 ` Jeff Law 0 siblings, 1 reply; 58+ messages in thread From: David Wohlferd @ 2015-11-16 1:23 UTC (permalink / raw) To: Segher Boessenkool; +Cc: gcc, rth, pinskia, Jeff Law, Sandra Loosemore [-- Attachment #1: Type: text/plain, Size: 3451 bytes --] On 11/9/2015 1:32 AM, Segher Boessenkool wrote: > On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote: >> It seems like a doc update is what is needed to close PR24414 (Old-style >> asms don't clobber memory). > What is needed to close the bug is to make the compiler work properly. The question of course is, what does 'properly' mean? My assertion is that 10 years on, 'properly' means whatever it's doing now. Changing it at this point will probably break more than it fixes, and (as you said) there is a plausible work-around using extended asm. So while this bug could be resolved as 'invalid' (since the compiler is behaving 'properly'), I'm thinking to split the difference and 'fix' it with a doc patch that describes the supported behavior. > Whether that means clobbering memory or not, I don't much care -- with > the status quo, if you want your asm to clobber memory you have to use > extended asm; if basic asm is made to clobber memory, if you want your > asm to *not* clobber memory you have to use extended asm (which you > can with no operands by writing e.g. asm("bork" : ); ). So both > behaviours are available whether we make a change or not. > > But changing things now will likely break user code. > >> Safely accessing C data and calling functions from basic @code{asm} is more >> -complex than it may appear. To access C data, it is better to use extended >> +complex than it may appear. To access C data (including both local and >> +global register variables), use extended >> @code{asm}. > I don't think this makes things clearer. Register vars are described > elsewhere already; The docs for local register variables describe this limitation. But globals does not. Whether this information belongs in local register, global register, basic asm, or all 3 depends on which section of the docs users will be reading when they need to know this information. > if you really think it needs mentioning here, put > it at the end (in its own sentence), don't break up this sentence. Ok. > (dot space space). > >> +Basic @code{asm} statements are not treated as though they used a "memory" >> +clobber, although they do implicitly perform a clobber of the flags >> +(@pxref{Clobbers}). > They do not clobber the flags. Observe: Ouch. i386 shows the same thing for basic asm. Having to preserve the flags is ugly, but since that's the behavior, let's write it down. > === > void f(int a) > { > a = a >> 2; > if (a <= 0) > asm("OHAI"); > if (a >= 0) > asm("OHAI2"); > } > === > > Compiling this for powerpc gives (-m32, edited): > > f: > srawi. 9,3,2 # this sets cr0 > ble 0,.L5 # this uses cr0 > .L2: > OHAI2 > blr > .p2align 4,,15 > .L5: > OHAI > bnelr 0 # this uses cr0 > b .L2 > > which shows that CR0 (which is "cc") is live over the asm. So are all > other condition regs. > > It is true for cc0 targets I guess, but there aren't many of those left. > >> Also, there is no implicit clobbering of registers, >> +so any registers changed must be restored to their original value before >> +exiting the @code{asm}. > One of the important uses of asm is to set registers GCC does not know > about, so you might want to phrase this differently. Ahh, good point. What would you say to "general purpose registers?" Update attached. dw [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 24414b.patch --] [-- Type: text/x-patch; name="24414b.patch", Size: 1329 bytes --] Index: extend.texi =================================================================== --- extend.texi (revision 229910) +++ extend.texi (working copy) @@ -7353,8 +7353,9 @@ @end itemize Safely accessing C data and calling functions from basic @code{asm} is more -complex than it may appear. To access C data, it is better to use extended -@code{asm}. +complex than it may appear. To access C data use extended @code{asm}. Do +not attempt to directly access local or global register variables from +within basic @code{asm} (@pxref{Explicit Register Variables}). Do not expect a sequence of @code{asm} statements to remain perfectly consecutive after compilation. If certain instructions need to remain @@ -7376,6 +7377,11 @@ visibility of any symbols it references. This may result in GCC discarding those symbols as unreferenced. +Basic @code{asm} statements are not treated as though they used a "memory" +clobber (@pxref{Clobbers}). Also, neither the flags nor the general-purpose +registers are clobbered, so any changes must be restored to their original +value before exiting the @code{asm}. + The compiler copies the assembler instructions in a basic @code{asm} verbatim to the assembly language output file, without processing dialects or any of the @samp{%} operators that are available with ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-16 1:23 ` David Wohlferd @ 2015-11-16 21:29 ` Jeff Law 2015-11-17 5:56 ` David Wohlferd 0 siblings, 1 reply; 58+ messages in thread From: Jeff Law @ 2015-11-16 21:29 UTC (permalink / raw) To: David Wohlferd, Segher Boessenkool; +Cc: gcc, rth, pinskia, Sandra Loosemore On 11/15/2015 06:23 PM, David Wohlferd wrote: > On 11/9/2015 1:32 AM, Segher Boessenkool wrote: >> On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote: >>> It seems like a doc update is what is needed to close PR24414 (Old-style >>> asms don't clobber memory). >> What is needed to close the bug is to make the compiler work properly. > > The question of course is, what does 'properly' mean? My assertion is > that 10 years on, 'properly' means whatever it's doing now. Changing it > at this point will probably break more than it fixes, and (as you said) > there is a plausible work-around using extended asm. > > So while this bug could be resolved as 'invalid' (since the compiler is > behaving 'properly'), I'm thinking to split the difference and 'fix' it > with a doc patch that describes the supported behavior. I'd disagree. A traditional asm has to be considered an opaque blob that read/write/clobber any register or memory location. It's also the case that assuming an old style asm can read or clobber any memory location is the safe, conservative thing to do. So the right thing in my mind is to ensure that behaviour and document it. Andrew's logic is just plain wrong in that BZ. > >> Whether that means clobbering memory or not, I don't much care -- with >> the status quo, if you want your asm to clobber memory you have to use >> extended asm; if basic asm is made to clobber memory, if you want your >> asm to *not* clobber memory you have to use extended asm (which you >> can with no operands by writing e.g. asm("bork" : ); ). So both >> behaviours are available whether we make a change or not. >> >> But changing things now will likely break user code. Having an traditional asm clobber memory should not break user code. It may pessimize it slightly, but if it does, that code was already broken. >> (dot space space). >> >>> +Basic @code{asm} statements are not treated as though they used a >>> "memory" >>> +clobber, although they do implicitly perform a clobber of the flags >>> +(@pxref{Clobbers}). >> They do not clobber the flags. Observe: > > Ouch. i386 shows the same thing for basic asm. Sadly, I suspect this isn't consistent across targets. Jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-16 21:29 ` Jeff Law @ 2015-11-17 5:56 ` David Wohlferd 2015-11-17 9:27 ` Andrew Haley 2015-11-17 21:31 ` Jeff Law 0 siblings, 2 replies; 58+ messages in thread From: David Wohlferd @ 2015-11-17 5:56 UTC (permalink / raw) To: Jeff Law, Segher Boessenkool; +Cc: gcc, rth, pinskia, Sandra Loosemore On 11/16/2015 1:29 PM, Jeff Law wrote: > On 11/15/2015 06:23 PM, David Wohlferd wrote: >> On 11/9/2015 1:32 AM, Segher Boessenkool wrote: >>> On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote: >>>> It seems like a doc update is what is needed to close PR24414 >>>> (Old-style >>>> asms don't clobber memory). >>> What is needed to close the bug is to make the compiler work properly. >> >> The question of course is, what does 'properly' mean? My assertion is >> that 10 years on, 'properly' means whatever it's doing now. Changing it >> at this point will probably break more than it fixes, and (as you said) >> there is a plausible work-around using extended asm. >> >> So while this bug could be resolved as 'invalid' (since the compiler is >> behaving 'properly'), I'm thinking to split the difference and 'fix' it >> with a doc patch that describes the supported behavior. > I'd disagree. A traditional asm has to be considered an opaque blob > that read/write/clobber any register or memory location. When I first encountered basic asm, my expectation was that of course it clobbers. It HAS to, right? But that said, let me give my best devil's advocate impersonation and ask: Why? - There is no standard that says it must do this. - I'm only aware of 1 person who has ever asked for this change. And the request has been deemed so unimportant it has languished for a very long time. - There is a plausible work-around with extended asm, which (mostly) has clear semantics regarding clobbers. - While the change probably won't introduce bad code, if it does it will be in ways that are going to be difficult to track down, in an area where few have the expertise to debug. - Existing code that currently does things 'right' (ie push/pop any modified registers) will suddenly be doing things 'wrong,' or at least wastefully. - Other than top-level asm, it seems like every existing basic asm will (probably) get a new performance penalty (memory usage + code size + cycles) to allow for situations they may already be handling correctly or that don't apply. True, these aren't particularly compelling reasons to not make the change. But I also don't see any compelling benefits to offset them. For existing users, presumably they have already found whatever solution they need and will just be annoyed that they have to revisit their code to see the impact of this change. Will they need to #if to ensure consistent performance/function between gcc versions? For future users, they will have the docs telling them the behavior, and pointing them to the (now well documented) extended asm. Where's the benefit? If someone were proposing basic asm as a new feature, I'd absolutely be arguing that it should clobber everything. Or I might argue that basic asm should only be allowed at top-level (where I don't believe clobbering matters?) and everything else should be extended asm so we KNOW what to clobber (hmm...). But changing this so gcc tries (probably futilely) to emulate other implementations of asm... That seems like a weak case to support a change to this long-time behavior. Unless there are other benefits I'm just not seeing? -------------- Ok, that's my best shot. You have way more expertise and experience here than I do, so I expect that after you think it over, you'll make the right call. And despite my attempt here to defend the opposite side, I'm not entirely sure what the right call is. But these seem like the right questions. Either way, let me know if I can help. > It's also the case that assuming an old style asm can read or clobber > any memory location is the safe, conservative thing to do. Well, safe-r. Even if you make this change, embedding basic asm in C routines still seems risky. Well, riskier than extended which is risky enough. > So the right thing in my mind is to ensure that behaviour The right thing in my mind is to find ways to prod people into using extended asm instead of basic. Then they explicitly specify their requirements rather than depending on clunky all-or-nothing defaults. Maybe to the extent of gcc deprecating (non-top level) basic over time (-fallow-basic-asm=[none|top|any] where v6 defaults to 'any' and v7 defaults to 'top'). I'd be surprised if gcc went this way, but that doesn't mean it wouldn't be better. > and document it. and to document it. > Andrew's logic is just plain wrong in that BZ. > > >> >>> Whether that means clobbering memory or not, I don't much care -- with >>> the status quo, if you want your asm to clobber memory you have to use >>> extended asm; if basic asm is made to clobber memory, if you want your >>> asm to *not* clobber memory you have to use extended asm (which you >>> can with no operands by writing e.g. asm("bork" : ); ). So both >>> behaviours are available whether we make a change or not. >>> >>> But changing things now will likely break user code. > Having an traditional asm clobber memory should not break user code. > It may pessimize it slightly, but if it does, that code was already > broken. How much pessimism are we talking here? Wouldn't clobbering everything effectively force the reloading of (some? most? all?) registers? And more memory will be needed to store things that used to just require registers? Along with a few more memory writes? A single line of basic asm, even a comment, could have a non-trivial impact on the code that gets generated. One common use I've seen for basic asm is "int $3" on x86 to break into the debugger (the basic asm docs use this as a sample). Changing this to a clobber-everything will make what used to be a minimally intrusive way to debug code into a high impact operation that may obscure the very thing being debugged. I see how this change might save users (at least the ones who don't read the docs) some confusion. Especially ones porting from other compilers that have a similar format for asm. But it's not going to help people who come from compilers that allow the asm to directly access C variables. Or that don't use strings and just embed the asm between braces. And if I weren't already using extended asm, the performance questions this introduces to basic would probably be enough to push me there. Or is that the intent? >>> (dot space space). >>> >>>> +Basic @code{asm} statements are not treated as though they used a >>>> "memory" >>>> +clobber, although they do implicitly perform a clobber of the flags >>>> +(@pxref{Clobbers}). >>> They do not clobber the flags. Observe: >> >> Ouch. i386 shows the same thing for basic asm. > Sadly, I suspect this isn't consistent across targets. Bigger ouch. I'll follow up on this after the discussion about changing basic asm is complete (which may render this moot). dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-17 5:56 ` David Wohlferd @ 2015-11-17 9:27 ` Andrew Haley 2015-11-17 21:31 ` Jeff Law 1 sibling, 0 replies; 58+ messages in thread From: Andrew Haley @ 2015-11-17 9:27 UTC (permalink / raw) To: gcc On 17/11/15 05:55, David Wohlferd wrote: > How much pessimism are we talking here? Wouldn't clobbering everything > effectively force the reloading of (some? most? all?) registers? And > more memory will be needed to store things that used to just require > registers? No, really not. It only affects locals whose address has been taken and is live at that point. > Along with a few more memory writes? A single line of basic asm, > even a comment, could have a non-trivial impact on the code that > gets generated. > > One common use I've seen for basic asm is "int $3" on x86 to break into > the debugger (the basic asm docs use this as a sample). Changing this to > a clobber-everything will make what used to be a minimally intrusive way > to debug code into a high impact operation that may obscure the very > thing being debugged. I think that's really pretty unlikely. Besides, if you need a breakpoint for debugging you really don't want operations to move across that breakpoint. Andrew. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-17 5:56 ` David Wohlferd 2015-11-17 9:27 ` Andrew Haley @ 2015-11-17 21:31 ` Jeff Law 2015-11-17 22:07 ` Andrew Pinski ` (2 more replies) 1 sibling, 3 replies; 58+ messages in thread From: Jeff Law @ 2015-11-17 21:31 UTC (permalink / raw) To: David Wohlferd, Segher Boessenkool; +Cc: gcc, rth, pinskia, Sandra Loosemore On 11/16/2015 10:55 PM, David Wohlferd wrote: > > - There is no standard that says it must do this. True. But these after all are extensions and extensions have been notoriously under-documented through the years. > - I'm only aware of 1 person who has ever asked for this change. And the > request has been deemed so unimportant it has languished for a very long > time. True. But I'd say for this case it means it just hasn't been high enough on anyone's priority list to get resolved. I wouldn't be at all surprised if Richard filed this bug to ensure that it didn't get lost. That's standard development procedure for items we notice, but aren't actively working on. It's unfortunate that Andrew muddied the waters. Andrew's conclusions, particularly in c#6 are simply wrong. > - There is a plausible work-around with extended asm, which (mostly) has > clear semantics regarding clobbers. Converting an old-style asm to extended asm can be painful. ANd in the case of legacy code the conversion process itself is a potential source of bugs. > - While the change probably won't introduce bad code, if it does it will > be in ways that are going to be difficult to track down, in an area > where few have the expertise to debug. > - Existing code that currently does things 'right' (ie push/pop any > modified registers) will suddenly be doing things 'wrong,' or at least > wastefully. > - Other than top-level asm, it seems like every existing basic asm will > (probably) get a new performance penalty (memory usage + code size + > cycles) to allow for situations they may already be handling correctly > or that don't apply. > True, these aren't particularly compelling reasons to not make the > change. But I also don't see any compelling benefits to offset them. The benefit is traditional asms do the expected thing. With no way to describe dataflow, the only rational behaviour for a traditional asm is that it has to be considered a use/clobber of memory and hard registers. The fact that it wasn't documented that way eons ago is simply a documentation bug -- likely due to the fact that back when the documentation for traditional asms was written, there were virtually no optimizations of memory referencing instructions -- essentially folks didn't ponder (much less document) how these asms would interact with memory. In fact, if you go back to the change I made back in 1999 referenced by this BZ, you'll find that we had a mis-compilation of code around an ASM by a pass to remove redundant stores that had just been significantly improved. > > For existing users, presumably they have already found whatever solution > they need and will just be annoyed that they have to revisit their code > to see the impact of this change. Will they need to #if to ensure > consistent performance/function between gcc versions? For future users, > they will have the docs telling them the behavior, and pointing them to > the (now well documented) extended asm. Where's the benefit? Existing users have to change nothing when we fix 24414. The whole point behind 24414 is to point out a case where we are not honoring the uses/clobbers all hard regs and memory semantics of traditional asms. > > But changing this so gcc tries (probably futilely) to emulate other > implementations of asm... That seems like a weak case to support a > change to this long-time behavior. Unless there are other benefits I'm > just not seeing? When we fix 24414 by honoring the "uses/clobbers all hard registers and memory" semantics for old-style asms, those old-style asms will be *less* likely to cause problems in the presence of ever-improving optimization techniques. > > -------------- > Ok, that's my best shot. You have way more expertise and experience > here than I do, so I expect that after you think it over, you'll make > the right call. And despite my attempt here to defend the opposite > side, I'm not entirely sure what the right call is. But these seem like > the right questions. > > Either way, let me know if I can help. About the only immediate task would be to ensure that the documentation for traditional asms clearly documents the desired semantics and somehow note that there are known bugs in the implementation (ie 24414, handling of flags registers, and probably other oddities) >>>> Whether that means clobbering memory or not, I don't much care -- with >>>> the status quo, if you want your asm to clobber memory you have to use >>>> extended asm; if basic asm is made to clobber memory, if you want your >>>> asm to *not* clobber memory you have to use extended asm (which you >>>> can with no operands by writing e.g. asm("bork" : ); ). So both >>>> behaviours are available whether we make a change or not. >>>> >>>> But changing things now will likely break user code. >> Having an traditional asm clobber memory should not break user code. >> It may pessimize it slightly, but if it does, that code was already >> broken. > > How much pessimism are we talking here? Wouldn't clobbering everything > effectively force the reloading of (some? most? all?) registers? And > more memory will be needed to store things that used to just require > registers? Along with a few more memory writes? A single line of basic > asm, even a comment, could have a non-trivial impact on the code that > gets generated. Essentially it means that old style asms become a point where the compiler has to assume that memory and hard registers are read/clobbered. Without going into all the details the asm essentially invalidates information the compiler might be tracking about the value in memory locations or hard registers. So given two stores to the same memory location on opposite sides of the traditional asm, the compiler is _not_ allowed to remove the first store (because the traditional asm might read the value). Nor is the compiler allowed to remove the second store (because the asm might have stored a value into that location). Similar situations occur when reading memory locations. > > One common use I've seen for basic asm is "int $3" on x86 to break into > the debugger (the basic asm docs use this as a sample). Changing this to > a clobber-everything will make what used to be a minimally intrusive way > to debug code into a high impact operation that may obscure the very > thing being debugged. Actually in that specific case, ensuring everything is consistent is actually a *good* thing. And I suspect it's still a lot less intrusive than you might think. >>>> +Basic @code{asm} statements are not treated as though they used a >>>>> "memory" >>>>> +clobber, although they do implicitly perform a clobber of the flags >>>>> +(@pxref{Clobbers}). >>>> They do not clobber the flags. Observe: >>> >>> Ouch. i386 shows the same thing for basic asm. >> Sadly, I suspect this isn't consistent across targets. > > Bigger ouch. I'll follow up on this after the discussion about changing > basic asm is complete (which may render this moot). It likely depends on how the target models the flags. jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-17 21:31 ` Jeff Law @ 2015-11-17 22:07 ` Andrew Pinski 2015-11-18 22:04 ` Jeff Law 2015-11-18 1:28 ` Segher Boessenkool 2015-11-20 1:24 ` David Wohlferd 2 siblings, 1 reply; 58+ messages in thread From: Andrew Pinski @ 2015-11-17 22:07 UTC (permalink / raw) To: Jeff Law; +Cc: David Wohlferd, Segher Boessenkool, gcc, rth, Sandra Loosemore On Wed, Nov 18, 2015 at 5:31 AM, Jeff Law <law@redhat.com> wrote: > On 11/16/2015 10:55 PM, David Wohlferd wrote: >> >> >> - There is no standard that says it must do this. > > True. But these after all are extensions and extensions have been > notoriously under-documented through the years. > >> - I'm only aware of 1 person who has ever asked for this change. And the >> request has been deemed so unimportant it has languished for a very long >> time. > > True. But I'd say for this case it means it just hasn't been high enough on > anyone's priority list to get resolved. I wouldn't be at all surprised if > Richard filed this bug to ensure that it didn't get lost. That's standard > development procedure for items we notice, but aren't actively working on. > > It's unfortunate that Andrew muddied the waters. Andrew's conclusions, > particularly in c#6 are simply wrong. Sorry about that. I have since changed my views on this matter to say old-style asm should clobber memory. I should have written this sooner but I have been busy with other things. Thanks, Andrew > > >> - There is a plausible work-around with extended asm, which (mostly) has >> clear semantics regarding clobbers. > > Converting an old-style asm to extended asm can be painful. ANd in the case > of legacy code the conversion process itself is a potential source of bugs. > > > > >> - While the change probably won't introduce bad code, if it does it will >> be in ways that are going to be difficult to track down, in an area >> where few have the expertise to debug. >> - Existing code that currently does things 'right' (ie push/pop any >> modified registers) will suddenly be doing things 'wrong,' or at least >> wastefully. >> - Other than top-level asm, it seems like every existing basic asm will >> (probably) get a new performance penalty (memory usage + code size + >> cycles) to allow for situations they may already be handling correctly >> or that don't apply. >> True, these aren't particularly compelling reasons to not make the >> change. But I also don't see any compelling benefits to offset them. > > The benefit is traditional asms do the expected thing. With no way to > describe dataflow, the only rational behaviour for a traditional asm is that > it has to be considered a use/clobber of memory and hard registers. > > The fact that it wasn't documented that way eons ago is simply a > documentation bug -- likely due to the fact that back when the documentation > for traditional asms was written, there were virtually no optimizations of > memory referencing instructions -- essentially folks didn't ponder (much > less document) how these asms would interact with memory. > > In fact, if you go back to the change I made back in 1999 referenced by this > BZ, you'll find that we had a mis-compilation of code around an ASM by a > pass to remove redundant stores that had just been significantly improved. > > > >> >> For existing users, presumably they have already found whatever solution >> they need and will just be annoyed that they have to revisit their code >> to see the impact of this change. Will they need to #if to ensure >> consistent performance/function between gcc versions? For future users, >> they will have the docs telling them the behavior, and pointing them to >> the (now well documented) extended asm. Where's the benefit? > > Existing users have to change nothing when we fix 24414. The whole point > behind 24414 is to point out a case where we are not honoring the > uses/clobbers all hard regs and memory semantics of traditional asms. > > >> >> But changing this so gcc tries (probably futilely) to emulate other >> implementations of asm... That seems like a weak case to support a >> change to this long-time behavior. Unless there are other benefits I'm >> just not seeing? > > When we fix 24414 by honoring the "uses/clobbers all hard registers and > memory" semantics for old-style asms, those old-style asms will be *less* > likely to cause problems in the presence of ever-improving optimization > techniques. > > >> >> -------------- >> Ok, that's my best shot. You have way more expertise and experience >> here than I do, so I expect that after you think it over, you'll make >> the right call. And despite my attempt here to defend the opposite >> side, I'm not entirely sure what the right call is. But these seem like >> the right questions. >> >> Either way, let me know if I can help. > > About the only immediate task would be to ensure that the documentation for > traditional asms clearly documents the desired semantics and somehow note > that there are known bugs in the implementation (ie 24414, handling of flags > registers, and probably other oddities) > >>>>> Whether that means clobbering memory or not, I don't much care -- with >>>>> the status quo, if you want your asm to clobber memory you have to use >>>>> extended asm; if basic asm is made to clobber memory, if you want your >>>>> asm to *not* clobber memory you have to use extended asm (which you >>>>> can with no operands by writing e.g. asm("bork" : ); ). So both >>>>> behaviours are available whether we make a change or not. >>>>> >>>>> But changing things now will likely break user code. >>> >>> Having an traditional asm clobber memory should not break user code. >>> It may pessimize it slightly, but if it does, that code was already >>> broken. >> >> >> How much pessimism are we talking here? Wouldn't clobbering everything >> effectively force the reloading of (some? most? all?) registers? And >> more memory will be needed to store things that used to just require >> registers? Along with a few more memory writes? A single line of basic >> asm, even a comment, could have a non-trivial impact on the code that >> gets generated. > > Essentially it means that old style asms become a point where the compiler > has to assume that memory and hard registers are read/clobbered. Without > going into all the details the asm essentially invalidates information the > compiler might be tracking about the value in memory locations or hard > registers. > > So given two stores to the same memory location on opposite sides of the > traditional asm, the compiler is _not_ allowed to remove the first store > (because the traditional asm might read the value). Nor is the compiler > allowed to remove the second store (because the asm might have stored a > value into that location). > > Similar situations occur when reading memory locations. > >> >> One common use I've seen for basic asm is "int $3" on x86 to break into >> the debugger (the basic asm docs use this as a sample). Changing this to >> a clobber-everything will make what used to be a minimally intrusive way >> to debug code into a high impact operation that may obscure the very >> thing being debugged. > > Actually in that specific case, ensuring everything is consistent is > actually a *good* thing. And I suspect it's still a lot less intrusive than > you might think. > >>>>> +Basic @code{asm} statements are not treated as though they used a >>>>>> >>>>>> "memory" >>>>>> +clobber, although they do implicitly perform a clobber of the flags >>>>>> +(@pxref{Clobbers}). >>>>> >>>>> They do not clobber the flags. Observe: >>>> >>>> >>>> Ouch. i386 shows the same thing for basic asm. >>> >>> Sadly, I suspect this isn't consistent across targets. >> >> >> Bigger ouch. I'll follow up on this after the discussion about changing >> basic asm is complete (which may render this moot). > > It likely depends on how the target models the flags. > > jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-17 22:07 ` Andrew Pinski @ 2015-11-18 22:04 ` Jeff Law 0 siblings, 0 replies; 58+ messages in thread From: Jeff Law @ 2015-11-18 22:04 UTC (permalink / raw) To: Andrew Pinski Cc: David Wohlferd, Segher Boessenkool, gcc, rth, Sandra Loosemore On 11/17/2015 03:07 PM, Andrew Pinski wrote: > On Wed, Nov 18, 2015 at 5:31 AM, Jeff Law <law@redhat.com> wrote: >> On 11/16/2015 10:55 PM, David Wohlferd wrote: >>> >>> >>> - There is no standard that says it must do this. >> >> True. But these after all are extensions and extensions have been >> notoriously under-documented through the years. >> >>> - I'm only aware of 1 person who has ever asked for this change. And the >>> request has been deemed so unimportant it has languished for a very long >>> time. >> >> True. But I'd say for this case it means it just hasn't been high enough on >> anyone's priority list to get resolved. I wouldn't be at all surprised if >> Richard filed this bug to ensure that it didn't get lost. That's standard >> development procedure for items we notice, but aren't actively working on. >> >> It's unfortunate that Andrew muddied the waters. Andrew's conclusions, >> particularly in c#6 are simply wrong. > > > Sorry about that. I have since changed my views on this matter to say > old-style asm should clobber memory. I should have written this > sooner but I have been busy with other things. I certainly understand being busy with other things. Thanks for chiming in and clarifying your current thoughts. Jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-17 21:31 ` Jeff Law 2015-11-17 22:07 ` Andrew Pinski @ 2015-11-18 1:28 ` Segher Boessenkool 2015-11-18 22:08 ` Jeff Law 2015-11-20 1:24 ` David Wohlferd 2 siblings, 1 reply; 58+ messages in thread From: Segher Boessenkool @ 2015-11-18 1:28 UTC (permalink / raw) To: Jeff Law; +Cc: David Wohlferd, gcc, rth, pinskia, Sandra Loosemore On Tue, Nov 17, 2015 at 02:31:29PM -0700, Jeff Law wrote: > >- There is a plausible work-around with extended asm, which (mostly) has > >clear semantics regarding clobbers. > Converting an old-style asm to extended asm can be painful. ANd in the > case of legacy code the conversion process itself is a potential source > of bugs. > >- While the change probably won't introduce bad code, if it does it will > >be in ways that are going to be difficult to track down, in an area > >where few have the expertise to debug. > >- Existing code that currently does things 'right' (ie push/pop any > >modified registers) will suddenly be doing things 'wrong,' or at least > >wastefully. Basic asm does not do this, and hasn't for a very long time. So there simply cannot be existing users that rely on this behaviour. fwprop1 removes the save/restore already, in most cases. > The fact that it wasn't documented that way eons ago is simply a > documentation bug -- likely due to the fact that back when the > documentation for traditional asms was written, there were virtually no > optimizations of memory referencing instructions -- essentially folks > didn't ponder (much less document) how these asms would interact with > memory. _Does_ basic asm as currently implemented have a memory clobber? If not, it seems we can just remove basic asm completely and everything would still work the same! Segher ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-18 1:28 ` Segher Boessenkool @ 2015-11-18 22:08 ` Jeff Law 0 siblings, 0 replies; 58+ messages in thread From: Jeff Law @ 2015-11-18 22:08 UTC (permalink / raw) To: Segher Boessenkool; +Cc: David Wohlferd, gcc, rth, pinskia, Sandra Loosemore On 11/17/2015 06:28 PM, Segher Boessenkool wrote: > > _Does_ basic asm as currently implemented have a memory clobber? If not, > it seems we can just remove basic asm completely and everything would > still work the same! You'd have to dig into the various optimizers -- I know that it has a memory use in DSE, but I haven't audited the optimizers thoroughly. In fact, the whole point behind the PR in question is there's at least one optimizer that is missing that check. Jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-17 21:31 ` Jeff Law 2015-11-17 22:07 ` Andrew Pinski 2015-11-18 1:28 ` Segher Boessenkool @ 2015-11-20 1:24 ` David Wohlferd 2015-11-20 1:53 ` Sandra Loosemore ` (2 more replies) 2 siblings, 3 replies; 58+ messages in thread From: David Wohlferd @ 2015-11-20 1:24 UTC (permalink / raw) To: Jeff Law, Segher Boessenkool; +Cc: gcc, rth, pinskia, Sandra Loosemore >> Unless there are other benefits I'm just not seeing? > When we fix 24414 by honoring the "uses/clobbers all hard registers > and memory" semantics for old-style asms, those old-style asms will be > *less* likely to cause problems in the presence of ever-improving > optimization techniques. Ok, this is a good point. In fact, it may resolve existing problems that people don't know they have. However I still have concerns that people might be surprised by the change in behavior. Looking thru the linux kernel source (a significant collection of inline asm containing both basic (~878) and extended (4833) statements), it seems there are places where they really are going to want the "clobber nothing" semantics. For that reason, I'd like to propose adding 2 new clobbers to extended asm as part of this work: "clobberall" - This gives extended the same semantics as whatever the new basic asm will be using. "clobbernone" - This gives the same semantics as the current basic asm. Clobbernone may seem redundant, since not specifying any clobbers should do the same thing. But actually it doesn't, at least on i386. At present, there is no way for extended asm to not clobber "cc". I don't know if other platforms have similar issues. When basic asm changes, I expect that having a way to "just do what it used to do" is going to be useful for some people. >> Either way, let me know if I can help. > About the only immediate task would be to ensure that the > documentation for traditional asms clearly documents the desired > semantics and somehow note that there are known bugs in the > implementation (ie 24414, handling of flags registers, and probably > other oddities) Given that gcc is at phase 3, I'm guessing this work won't be in v6? Or would this be considered "general bugfixing?" The reason I ask is I want to clearly document what the current behavior is as well as informing them about what's coming. If this isn't changing until v7, the text can be updated then to reflect the new behavior. > And I suspect it's still a lot less intrusive than you might think. I tried to picture the most basic case I can think of that uses something clobber-able: for (int x=0; x < 1000; x++) asm("#stuff"); This generates very simple and highly performant code: movl $1000, %eax .L2: #stuff subl $1, %eax jne .L2 Using extended asm to simulate the clobberall gives: movl $1000, 44(%rsp) .L2: #stuff subl $1, 44(%rsp) jne .L2 It allocates an extra 4 bytes, and changed everything to memory accesses instead of using a register. Obviously not a huge performance impact on this tiny sample, but it does suggest to me that sometimes there could be. My point being simply that people may want the old behavior, so we need to be sure there's a way to get it (ie "clobbernone"). >>>>> +Basic @code{asm} statements are not treated as though they used a >>>>>> "memory" >>>>>> +clobber, although they do implicitly perform a clobber of the flags >>>>>> +(@pxref{Clobbers}). >>>>> They do not clobber the flags. Observe: >>>> >>>> Ouch. i386 shows the same thing for basic asm. >>> Sadly, I suspect this isn't consistent across targets. >> >> Bigger ouch. I'll follow up on this after the discussion about changing >> basic asm is complete (which may render this moot). > It likely depends on how the target models the flags. I'm not quite sure how to proceed here. I'm pretty sure no one wants me to write "basic asm doesn't clobber flags, except that maybe it does on some (unspecified) platforms." I've tried to follow the code, but without any particular success. I was hoping to see decode_reg_name_and_count (or decode_reg_name) being called from platform-specific routines and handling -3, but not so much. Using users as beta testers is normally frowned upon (outside of Microsoft), but perhaps the solution here is to just say that it doesn't clobber flags (currently the most common case?), and update the docs if and when people complain? Yes, that's bad, but saying nothing at all isn't any better. And we know it's true for at least 2 platforms. dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 1:24 ` David Wohlferd @ 2015-11-20 1:53 ` Sandra Loosemore 2015-11-22 5:09 ` David Wohlferd 2015-11-20 3:14 ` Segher Boessenkool 2015-11-20 10:17 ` Andrew Haley 2 siblings, 1 reply; 58+ messages in thread From: Sandra Loosemore @ 2015-11-20 1:53 UTC (permalink / raw) To: David Wohlferd, Jeff Law, Segher Boessenkool; +Cc: gcc, rth, pinskia On 11/19/2015 06:23 PM, David Wohlferd wrote: >> About the only immediate task would be to ensure that the >> documentation for traditional asms clearly documents the desired >> semantics and somehow note that there are known bugs in the >> implementation (ie 24414, handling of flags registers, and probably >> other oddities) > > Given that gcc is at phase 3, I'm guessing this work won't be in v6? Or > would this be considered "general bugfixing?" > > The reason I ask is I want to clearly document what the current behavior > is as well as informing them about what's coming. If this isn't > changing until v7, the text can be updated then to reflect the new > behavior. Documentation fixes are accepted all the way through Stage 4, since there's less risk of introducing regressions in user programs from accidental documentation mistakes than code errors. OTOH, I'd discourage adding anything to the docs about anticipated changes in future releases, except possibly to note that certain features or behavior are deprecated and may be removed in future releases (with a suggestion about what you should do instead). We've already got too many "maybe someday this will be fixed" notes in the manual that are not terribly useful to users. -Sandra ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 1:53 ` Sandra Loosemore @ 2015-11-22 5:09 ` David Wohlferd 0 siblings, 0 replies; 58+ messages in thread From: David Wohlferd @ 2015-11-22 5:09 UTC (permalink / raw) To: Sandra Loosemore; +Cc: Jeff Law, Segher Boessenkool, gcc, rth, pinskia On 11/19/2015 5:53 PM, Sandra Loosemore wrote: > On 11/19/2015 06:23 PM, David Wohlferd wrote: > >>> About the only immediate task would be to ensure that the >>> documentation for traditional asms clearly documents the desired >>> semantics and somehow note that there are known bugs in the >>> implementation (ie 24414, handling of flags registers, and probably >>> other oddities) >> >> Given that gcc is at phase 3, I'm guessing this work won't be in v6? Or >> would this be considered "general bugfixing?" >> >> The reason I ask is I want to clearly document what the current behavior >> is as well as informing them about what's coming. If this isn't >> changing until v7, the text can be updated then to reflect the new >> behavior. > > Documentation fixes are accepted all the way through Stage 4, since > there's less risk of introducing regressions in user programs from > accidental documentation mistakes than code errors. The code change isn't yet finalized. I'm hoping to doc something vaguely like: "basic asm (other than at top level) is being deprecated because <blah blah> potentially unsafe due to optimizations <blah blah blah>. You can locate the statements that will no longer be supported using -Wonly-top-basic-asm. Change them to use extended asm instead." What's your take on having the user guide link to the gcc wiki? If we do make this change, I'd kinda like to create a "how to convert basic asm to extended." But it doesn't seem like a good fit for the user docs. But if the user docs don't reference the wiki, I doubt anyone would ever find it. > OTOH, I'd discourage adding anything to the docs about anticipated > changes in future releases, except possibly to note that certain > features or behavior are deprecated and may be removed in future > releases (with a suggestion about what you should do instead). I'd love to see the doc folks make a pass and remove every "some day this won't work" text that doesn't include this. If there is no way for users to prepare, you aren't helping. And remove all the "some day there might be a new feature" stuff too. It just wastes users' time trying to figure out if "some day" has arrived yet. And it makes them cry when the new feature, which is exactly what they need, isn't there yet. > We've already got too many "maybe someday this will be fixed" notes in > the manual that are not terribly useful to users. You'd get my vote to remove them all. If I got a vote. dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 1:24 ` David Wohlferd 2015-11-20 1:53 ` Sandra Loosemore @ 2015-11-20 3:14 ` Segher Boessenkool 2015-11-20 10:45 ` David Wohlferd 2015-11-20 10:17 ` Andrew Haley 2 siblings, 1 reply; 58+ messages in thread From: Segher Boessenkool @ 2015-11-20 3:14 UTC (permalink / raw) To: David Wohlferd; +Cc: Jeff Law, gcc, rth, pinskia, Sandra Loosemore On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote: > For that reason, I'd like to propose adding 2 new clobbers to extended > asm as part of this work: > > "clobberall" - This gives extended the same semantics as whatever the > new basic asm will be using. > "clobbernone" - This gives the same semantics as the current basic asm. I don't think this is necessary or useful. They are also awful names: "clobberall" cannot clobber everything (think of the stack pointer), and "clobbernone" does clobber some (those clobbered by any asm), > Clobbernone may seem redundant, since not specifying any clobbers should > do the same thing. But actually it doesn't, at least on i386. At > present, there is no way for extended asm to not clobber "cc". I don't > know if other platforms have similar issues. Some do. The purpose is to stay compatible with asm written for older versions of the compiler. > When basic asm changes, I expect that having a way to "just do what it > used to do" is going to be useful for some people. 24414 says the documented behaviour hasn't been true for at least fourteen years. It isn't likely anyone is relying on that behaviour. > but perhaps the solution here is to just say that it doesn't > clobber flags (currently the most common case?), and update the docs if > and when people complain? Yes, that's bad, but saying nothing at all > isn't any better. And we know it's true for at least 2 platforms. Saying nothing at all at least is *correct*. It isn't necessary for users to know what registers the compiler considers to be clobbered by an asm, unless they actually clobber something in the assembler code themselves. They can write extended asm in that case. Maybe you can put that in the doc? "If you modify any register or memory, use an extended asm"? Jeff, do you agree with that? Segher ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 3:14 ` Segher Boessenkool @ 2015-11-20 10:45 ` David Wohlferd 2015-11-20 14:56 ` Segher Boessenkool 0 siblings, 1 reply; 58+ messages in thread From: David Wohlferd @ 2015-11-20 10:45 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Jeff Law, gcc, rth, pinskia, Sandra Loosemore On 11/19/2015 7:14 PM, Segher Boessenkool wrote: > On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote: >> For that reason, I'd like to propose adding 2 new clobbers to extended >> asm as part of this work: >> >> "clobberall" - This gives extended the same semantics as whatever the >> new basic asm will be using. >> "clobbernone" - This gives the same semantics as the current basic asm. > I don't think this is necessary or useful. They are also awful names: > "clobberall" cannot clobber everything (think of the stack pointer), I'm not emotionally attached to the names. But providing the same capability to extended that we are proposing for basic doesn't seem so odd. Shouldn't extended be able to do (at least) everything basic does? My first thought is that it allows people to incrementally start migrating from (new) basic to extended (something I think we should encourage). Or use it as a debug tool to see if the failure you are experiencing from your asm is due to a missing clobber. Since the capability will already be implemented for basic, providing a way to access it from extended seems trivial (if we can agree on a name). As you say, clobbering the stack pointer presents special challenges (although gcc has a specific way of dealing with stack register clobbers, see 52813). This is why I described the feature as having "the same semantics as whatever the new basic asm will be using." > and "clobbernone" does clobber some (those clobbered by any asm), Seems like a quibble. Those other things (I assume you mean things like pipelining?) most users aren't even aware of (or they wouldn't be so eager to use inline asm in the first place). Would it be more palatable if we called it "v5BasicAsmMode"? "ClobberMin"? >> Clobbernone may seem redundant, since not specifying any clobbers should >> do the same thing. But actually it doesn't, at least on i386. At >> present, there is no way for extended asm to not clobber "cc". I don't >> know if other platforms have similar issues. > Some do. The purpose is to stay compatible with asm written for older > versions of the compiler. Backward compatibility is important. I understand that due to the cc0 change in x86, existing code may have broken without always clobbering cc. This was seen as the safest way to ensure that didn't happen. However no solution was/is available for people who correctly knew whether their asm clobbers the flags. Mostly I'm ok with that. All the ways that I can think of to try to re-allow people to start using the cc clobber are just not worth it. I simply can't believe there are many cases where there's going to be a benefit. But as I said: backward compatibility is important. Providing a way for people who need/want the old basic asm semantics seems useful. And I don't believe we can (quite) do that without clobbernone. >> When basic asm changes, I expect that having a way to "just do what it >> used to do" is going to be useful for some people. > 24414 says the documented behaviour hasn't been true for at least > fourteen years. It isn't likely anyone is relying on that behaviour. ? To my knowledge, there was no documentation of any sort about what basic asm clobbered until I added it. But what people are (presumably) relying on is that whatever it did in the last version, it's going to continue to do that in the next. And albeit with good intentions, we are planning on changing that. >> but perhaps the solution here is to just say that it doesn't >> clobber flags (currently the most common case?), and update the docs if >> and when people complain? Yes, that's bad, but saying nothing at all >> isn't any better. And we know it's true for at least 2 platforms. > Saying nothing at all at least is *correct*. We don't know that saying "it doesn't clobber flags" is wrong either. All we know is that jeff said "I suspect this isn't consistent across targets." But that's neither here nor there. The real question is, if we can't say that, what can we say? - If 24414 is going in v6, then we can doc that it does the clobber and be vague about the old behavior. - If 24414 isn't going in v6, then what? I suppose we can say that it can vary by platform. We could even provide your sample code as a means for people to discover their platform's behavior. > It isn't necessary for users to know what registers the compiler > considers to be clobbered by an asm, unless they actually clobber > something in the assembler code themselves. I'm not sure I follow. If someone has code that uses a register, currently they must restore the value before exiting the asm or risk disaster. So they might write asm("push eax ; DoSomethingWith eax ; pop eax"). However if you know that the compiler is going to clobber eax, then the push/pop is just a waste of cycles and memory. To write efficient code, it seems like you do need to know what the compiler clobbers. > They can write extended asm in that case. I agree that if they did that it would solve the problem. But... > Maybe you can put that in the doc? "If you modify any register or > memory, use an extended asm"? Jeff, do you agree with that? Well, I'm already on record as saying I think any asm that isn't top level should be extended, so I'm pretty much ok with that. But that raises the question: - If this is the requirement for using basic asm, why do we need to change its behavior at all? Yes, code that uses registers or memory might fail due to optimizations, but such code would be in violation of supported usage. - If registers and memory access are still supported in basic asm, what's the point of doc'ing that you can't? dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 10:45 ` David Wohlferd @ 2015-11-20 14:56 ` Segher Boessenkool 2015-11-20 20:01 ` Jeff Law 0 siblings, 1 reply; 58+ messages in thread From: Segher Boessenkool @ 2015-11-20 14:56 UTC (permalink / raw) To: David Wohlferd; +Cc: Jeff Law, gcc, rth, pinskia, Sandra Loosemore On Fri, Nov 20, 2015 at 02:45:05AM -0800, David Wohlferd wrote: > On 11/19/2015 7:14 PM, Segher Boessenkool wrote: > >On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote: > >>For that reason, I'd like to propose adding 2 new clobbers to extended > >>asm as part of this work: > >> > >>"clobberall" - This gives extended the same semantics as whatever the > >>new basic asm will be using. > >>"clobbernone" - This gives the same semantics as the current basic asm. > >I don't think this is necessary or useful. They are also awful names: > >"clobberall" cannot clobber everything (think of the stack pointer), > > I'm not emotionally attached to the names. Names should be succinct, clear, and give a good indication of what the thing named does. If it is hard to make a good name it is likely that the interface isn't so well designed. > But providing the same > capability to extended that we are proposing for basic doesn't seem so > odd. Shouldn't extended be able to do (at least) everything basic does? But that would be logical! Can't have that. Heh. > As you say, clobbering the stack pointer presents special challenges > (although gcc has a specific way of dealing with stack register > clobbers, see 52813). Yeah. Actually, basic asm is handled specially in many places, too. > >and "clobbernone" does clobber some (those clobbered by any asm), > > Seems like a quibble. Those other things (I assume you mean things like > pipelining?) most users aren't even aware of (or they wouldn't be so > eager to use inline asm in the first place). Would it be more palatable > if we called it "v5BasicAsmMode"? "ClobberMin"? I meant things like x86 "cc". > >>Clobbernone may seem redundant, since not specifying any clobbers should > >>do the same thing. But actually it doesn't, at least on i386. At > >>present, there is no way for extended asm to not clobber "cc". I don't > >>know if other platforms have similar issues. > >Some do. The purpose is to stay compatible with asm written for older > >versions of the compiler. > > Backward compatibility is important. I understand that due to the cc0 > change in x86, existing code may have broken without always clobbering > cc. This was seen as the safest way to ensure that didn't happen. > However no solution was/is available for people who correctly knew > whether their asm clobbers the flags. > > Mostly I'm ok with that. All the ways that I can think of to try to > re-allow people to start using the cc clobber are just not worth it. I > simply can't believe there are many cases where there's going to be a > benefit. Exactly. The asm still can be moved "over" other uses of CC, it does not limit transformations much at all. > But as I said: backward compatibility is important. Providing a way for > people who need/want the old basic asm semantics seems useful. And I > don't believe we can (quite) do that without clobbernone. > > >>When basic asm changes, I expect that having a way to "just do what it > >>used to do" is going to be useful for some people. > >24414 says the documented behaviour hasn't been true for at least > >fourteen years. It isn't likely anyone is relying on that behaviour. > > ? 24414 says these things haven't worked since at least 2.95.3, which is fourteen years old now. > >It isn't necessary for users to know what registers the compiler > >considers to be clobbered by an asm, unless they actually clobber > >something in the assembler code themselves. > > I'm not sure I follow. If the assembler code does not clobber some register, but GCC treats it as if it does, things will work correctly. Segher ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 14:56 ` Segher Boessenkool @ 2015-11-20 20:01 ` Jeff Law 2015-11-20 22:07 ` Paul_Koning 0 siblings, 1 reply; 58+ messages in thread From: Jeff Law @ 2015-11-20 20:01 UTC (permalink / raw) To: Segher Boessenkool, David Wohlferd; +Cc: gcc, rth, pinskia, Sandra Loosemore On 11/20/2015 07:56 AM, Segher Boessenkool wrote: >>>> When basic asm changes, I expect that having a way to "just do what it >>>> used to do" is going to be useful for some people. >>> 24414 says the documented behaviour hasn't been true for at least >>> fourteen years. It isn't likely anyone is relying on that behaviour. >> >> ? > > 24414 says these things haven't worked since at least 2.95.3, which is > fourteen years old now. That's not a good reason to leave things as-is. The problem is that optimizers continue to improve. So an old-style asm that worked in the past may mysteriously start failing as folks move forward with their compiler -- because we haven't properly implemented the right semantics of old-style asms, which is in part because certain aspects were never documented properly and partly because of reload issues :( If we keep old style asms, then we need to properly document what their behaviour is supposed to be, and continue to fix bugs where we do not honor that behaviour. The latter is somewhat painful because we don't have a single place where we can audit & fix any semantic problems. It's scattered in various optimizers throughout GCC. And I suspect most are getting it wrong in one way or another. Jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 20:01 ` Jeff Law @ 2015-11-20 22:07 ` Paul_Koning 0 siblings, 0 replies; 58+ messages in thread From: Paul_Koning @ 2015-11-20 22:07 UTC (permalink / raw) To: law; +Cc: segher, dw, gcc, rth, pinskia, sandra > On Nov 20, 2015, at 3:01 PM, Jeff Law <law@redhat.com> wrote: > > On 11/20/2015 07:56 AM, Segher Boessenkool wrote: > >>>>> When basic asm changes, I expect that having a way to "just do what it >>>>> used to do" is going to be useful for some people. >>>> 24414 says the documented behaviour hasn't been true for at least >>>> fourteen years. It isn't likely anyone is relying on that behaviour. >>> >>> ? >> >> 24414 says these things haven't worked since at least 2.95.3, which is >> fourteen years old now. > That's not a good reason to leave things as-is. > > The problem is that optimizers continue to improve. So an old-style asm that worked in the past may mysteriously start failing as folks move forward with their compiler -- because we haven't properly implemented the right semantics of old-style asms, which is in part because certain aspects were never documented properly and partly because of reload issues :( > > If we keep old style asms, then we need to properly document what their behaviour is supposed to be, and continue to fix bugs where we do not honor that behaviour. Yes. I know I've run into cases before where certain documented properties were not honored. I can't find the details right now; I think it was "old style asm always behaves as if marked 'volatile'. " paul ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 1:24 ` David Wohlferd 2015-11-20 1:53 ` Sandra Loosemore 2015-11-20 3:14 ` Segher Boessenkool @ 2015-11-20 10:17 ` Andrew Haley 2015-11-20 10:38 ` David Wohlferd 2 siblings, 1 reply; 58+ messages in thread From: Andrew Haley @ 2015-11-20 10:17 UTC (permalink / raw) To: David Wohlferd, Jeff Law, Segher Boessenkool Cc: gcc, rth, pinskia, Sandra Loosemore On 20/11/15 01:23, David Wohlferd wrote: > I tried to picture the most basic case I can think of that uses > something clobber-able: > > for (int x=0; x < 1000; x++) > asm("#stuff"); > > This generates very simple and highly performant code: > > movl $1000, %eax > .L2: > #stuff > subl $1, %eax > jne .L2 > > Using extended asm to simulate the clobberall gives: > > movl $1000, 44(%rsp) > .L2: > #stuff > subl $1, 44(%rsp) > jne .L2 > > It allocates an extra 4 bytes, and changed everything to memory accesses > instead of using a register. Can you show us your code? I get xx: movl $1000, %eax .L2: #stuff subl $1, %eax jne .L2 rep; ret for void xx() { for (int x=0; x < 1000; x++) asm volatile("#stuff" : : : "memory"); } What you're describing looks like a bug: x doesn't have its address taken. Andrew. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 10:17 ` Andrew Haley @ 2015-11-20 10:38 ` David Wohlferd 2015-11-20 11:14 ` Andrew Haley 0 siblings, 1 reply; 58+ messages in thread From: David Wohlferd @ 2015-11-20 10:38 UTC (permalink / raw) To: Andrew Haley, Jeff Law, Segher Boessenkool Cc: gcc, rth, pinskia, Sandra Loosemore On 11/20/2015 2:17 AM, Andrew Haley wrote: > On 20/11/15 01:23, David Wohlferd wrote: >> I tried to picture the most basic case I can think of that uses >> something clobber-able: >> >> for (int x=0; x < 1000; x++) >> asm("#stuff"); >> >> This generates very simple and highly performant code: >> >> movl $1000, %eax >> .L2: >> #stuff >> subl $1, %eax >> jne .L2 >> >> Using extended asm to simulate the clobberall gives: >> >> movl $1000, 44(%rsp) >> .L2: >> #stuff >> subl $1, 44(%rsp) >> jne .L2 >> >> It allocates an extra 4 bytes, and changed everything to memory accesses >> instead of using a register. > Can you show us your code? I get > > xx: > movl $1000, %eax > .L2: > #stuff > subl $1, %eax > jne .L2 > rep; ret > > for > > void xx() { > for (int x=0; x < 1000; x++) > asm volatile("#stuff" : : : "memory"); > } > > What you're describing looks like a bug: x doesn't have its address > taken. The intent for 24414 is to change basic asm such that it will become (quoting jeff) "an opaque blob that read/write/clobber any register or memory location." Such being the case, "memory" is not sufficient: #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory" int main() { for (int x=0; x < 1000; x++) asm("#":::CLOBBERALL); } dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 10:38 ` David Wohlferd @ 2015-11-20 11:14 ` Andrew Haley 2015-11-20 12:38 ` David Wohlferd 2015-11-20 16:41 ` Jeff Law 0 siblings, 2 replies; 58+ messages in thread From: Andrew Haley @ 2015-11-20 11:14 UTC (permalink / raw) To: David Wohlferd, Jeff Law, Segher Boessenkool Cc: gcc, rth, pinskia, Sandra Loosemore On 20/11/15 10:37, David Wohlferd wrote: > The intent for 24414 is to change basic asm such that it will become > (quoting jeff) "an opaque blob that read/write/clobber any register or > memory location." Such being the case, "memory" is not sufficient: > > #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11", > "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory" Hmm. I would not be at all surprised to see this cause reload failures. You certainly shouldn't clobber the frame pointer on any machine which needs one. Andrew. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 11:14 ` Andrew Haley @ 2015-11-20 12:38 ` David Wohlferd 2015-11-20 13:05 ` Richard Henderson 2015-11-20 16:41 ` Jeff Law 1 sibling, 1 reply; 58+ messages in thread From: David Wohlferd @ 2015-11-20 12:38 UTC (permalink / raw) To: Andrew Haley Cc: Jeff Law, Segher Boessenkool, gcc, rth, pinskia, Sandra Loosemore On 11/20/2015 3:14 AM, Andrew Haley wrote: > On 20/11/15 10:37, David Wohlferd wrote: >> The intent for 24414 is to change basic asm such that it will become >> (quoting jeff) "an opaque blob that read/write/clobber any register or >> memory location." Such being the case, "memory" is not sufficient: >> >> #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11", >> "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory" > Hmm. I would not be at all surprised to see this cause reload > failures. You certainly shouldn't clobber the frame pointer on > any machine which needs one. If I don't clobber ebp, gcc just uses it: movl $1000, %ebp .L2: # subl $1, %ebp jne .L2 The original purpose of this code was to attempt to show that this kind of "clobbering everything" behavior (the proposed new behavior for basic asm) could have non-trivial impact on existing routines. While I've been told that changing the existing "clobber nothing" approach to this kind of "clobber everything" is "less intrusive than you might think," I'm struggling to believe it. It seems to me that one asm("nop") thrown into a driver routine to fix a timing problem could end up making a real mess. But actually we're kind of past that. When Jeff, Segher, (other) Andrew and Richard all say "this is how it's going to work," it's time for me to set aside my reservations and move on. So now I'm just trying my best to make sure that if it *is* an issue, people have a viable solution readily available. And to make sure it's all correctly doc'ed (which is what started this whole mess). dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 12:38 ` David Wohlferd @ 2015-11-20 13:05 ` Richard Henderson 2015-11-20 15:20 ` Segher Boessenkool ` (2 more replies) 0 siblings, 3 replies; 58+ messages in thread From: Richard Henderson @ 2015-11-20 13:05 UTC (permalink / raw) To: David Wohlferd, Andrew Haley Cc: Jeff Law, Segher Boessenkool, gcc, rth, pinskia, Sandra Loosemore On 11/20/2015 01:38 PM, David Wohlferd wrote: > On 11/20/2015 3:14 AM, Andrew Haley wrote: >> On 20/11/15 10:37, David Wohlferd wrote: >>> The intent for 24414 is to change basic asm such that it will become >>> (quoting jeff) "an opaque blob that read/write/clobber any register or >>> memory location." Such being the case, "memory" is not sufficient: >>> >>> #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11", >>> "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory" >> Hmm. I would not be at all surprised to see this cause reload >> failures. You certainly shouldn't clobber the frame pointer on >> any machine which needs one. > > If I don't clobber ebp, gcc just uses it: > > movl $1000, %ebp > .L2: > # > subl $1, %ebp > jne .L2 I believe you'd have to have magic in there to conditionally clobber the register if it isn't being used as a frame pointer. That said... > The original purpose of this code was to attempt to show that this kind of > "clobbering everything" behavior (the proposed new behavior for basic asm) > could have non-trivial impact on existing routines. While I've been told that > changing the existing "clobber nothing" approach to this kind of "clobber > everything" is "less intrusive than you might think," I'm struggling to believe > it. It seems to me that one asm("nop") thrown into a driver routine to fix a > timing problem could end up making a real mess. > > But actually we're kind of past that. When Jeff, Segher, (other) Andrew and > Richard all say "this is how it's going to work," it's time for me to set aside > my reservations and move on. > > So now I'm just trying my best to make sure that if it *is* an issue, people > have a viable solution readily available. And to make sure it's all correctly > doc'ed (which is what started this whole mess). I'd be perfectly happy to deprecate and later completely remove basic asm within functions. Because IMO it's essentially useless. It has no inputs, no outputs, and no way to tell the compiler what machine state has been changed. We can say that "it clobbers everything", but that's not actually useful, and quite difficult as you're finding out. It seems to me that it would be better to remove the feature, forcing what must be an extremely small number of users to audit and update to extended asm. r~ ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 13:05 ` Richard Henderson @ 2015-11-20 15:20 ` Segher Boessenkool 2015-11-20 15:30 ` Richard Henderson 2015-11-20 18:24 ` Jeff Law 2015-11-26 10:30 ` Hans-Peter Nilsson 2 siblings, 1 reply; 58+ messages in thread From: Segher Boessenkool @ 2015-11-20 15:20 UTC (permalink / raw) To: Richard Henderson Cc: David Wohlferd, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote: > I'd be perfectly happy to deprecate and later completely remove basic asm > within functions. > > Because IMO it's essentially useless. It has no inputs, no outputs, and no > way to tell the compiler what machine state has been changed. We can say > that "it clobbers everything", but that's not actually useful, and quite > difficult as you're finding out. > > It seems to me that it would be better to remove the feature, forcing what > must be an extremely small number of users to audit and update to extended > asm. Should asm("bla"); then be an extended asm with no input, no outputs, no (non-automatic) clobbers? That would be the most straightforward and logical semantics, but will it break user code? Segher ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 15:20 ` Segher Boessenkool @ 2015-11-20 15:30 ` Richard Henderson 2015-11-20 15:34 ` Jakub Jelinek ` (2 more replies) 0 siblings, 3 replies; 58+ messages in thread From: Richard Henderson @ 2015-11-20 15:30 UTC (permalink / raw) To: Segher Boessenkool Cc: David Wohlferd, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On 11/20/2015 04:20 PM, Segher Boessenkool wrote: > On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote: >> I'd be perfectly happy to deprecate and later completely remove basic asm >> within functions. >> >> Because IMO it's essentially useless. It has no inputs, no outputs, and no >> way to tell the compiler what machine state has been changed. We can say >> that "it clobbers everything", but that's not actually useful, and quite >> difficult as you're finding out. >> >> It seems to me that it would be better to remove the feature, forcing what >> must be an extremely small number of users to audit and update to extended >> asm. > > Should asm("bla"); then be an extended asm with no input, no outputs, > no (non-automatic) clobbers? That would be the most straightforward and > logical semantics, but will it break user code? I'm suggesting that we don't accept that at all inside a function. One must audit the source and make a conscious decision to write asm("bla" : ); instead. Accepting basic asm outside of a function is perfectly ok, since that's just a mechanism by which one can inject complete assembly routines into a C translation unit. r~ ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 15:30 ` Richard Henderson @ 2015-11-20 15:34 ` Jakub Jelinek 2015-11-20 16:14 ` Richard Henderson 2015-11-20 16:21 ` Segher Boessenkool 2015-11-27 17:45 ` Segher Boessenkool 2 siblings, 1 reply; 58+ messages in thread From: Jakub Jelinek @ 2015-11-20 15:34 UTC (permalink / raw) To: Richard Henderson Cc: Segher Boessenkool, David Wohlferd, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote: > On 11/20/2015 04:20 PM, Segher Boessenkool wrote: > >On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote: > >>I'd be perfectly happy to deprecate and later completely remove basic asm > >>within functions. > >> > >>Because IMO it's essentially useless. It has no inputs, no outputs, and no > >>way to tell the compiler what machine state has been changed. We can say > >>that "it clobbers everything", but that's not actually useful, and quite > >>difficult as you're finding out. > >> > >>It seems to me that it would be better to remove the feature, forcing what > >>must be an extremely small number of users to audit and update to extended > >>asm. > > > >Should asm("bla"); then be an extended asm with no input, no outputs, > >no (non-automatic) clobbers? That would be the most straightforward and > >logical semantics, but will it break user code? > > I'm suggesting that we don't accept that at all inside a function. One must > audit the source and make a conscious decision to write asm("bla" : ); > instead. > > Accepting basic asm outside of a function is perfectly ok, since that's just > a mechanism by which one can inject complete assembly routines into a C > translation unit. Isn't that going to break too much code though? I mean, e.g. including libgcc... Jakub ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 15:34 ` Jakub Jelinek @ 2015-11-20 16:14 ` Richard Henderson 2015-11-20 23:56 ` David Wohlferd 0 siblings, 1 reply; 58+ messages in thread From: Richard Henderson @ 2015-11-20 16:14 UTC (permalink / raw) To: Jakub Jelinek Cc: Segher Boessenkool, David Wohlferd, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On 11/20/2015 04:34 PM, Jakub Jelinek wrote: > Isn't that going to break too much code though? I mean, e.g. including > libgcc... I don't know. My suspicion is very little. But that's actually what I'd like to know before we start adjusting code in other ways wrt basic asms. r~ ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 16:14 ` Richard Henderson @ 2015-11-20 23:56 ` David Wohlferd 2015-11-21 12:57 ` David Wohlferd 0 siblings, 1 reply; 58+ messages in thread From: David Wohlferd @ 2015-11-20 23:56 UTC (permalink / raw) To: Richard Henderson, Jakub Jelinek Cc: Segher Boessenkool, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On 11/20/2015 8:14 AM, Richard Henderson wrote: > On 11/20/2015 04:34 PM, Jakub Jelinek wrote: >> Isn't that going to break too much code though? I mean, e.g. including >> libgcc... > > I don't know. My suspicion is very little. > > But that's actually what I'd like to know before we start adjusting > code in other ways wrt basic asms. I can provide a little data here. In an effort to gain some perspective, I've been looking at inline asm usage in the linux kernel (4.3). Clearly this isn't "typical usage," but it is probably one of the biggest users of inline asm, and likely has the best justifications for doing so (being an OS and all). There are ~5,711 instances of inline asm in use. Of those, ~4,833 are extended and ~878 are basic. I don't have any numbers about how many are top level vs in function, but let me see what I can do. A quick look at libgcc shows that there are 109 extended and 45 basic asm statements. I'll see how many end up being top-level, but it looks like most of them. dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 23:56 ` David Wohlferd @ 2015-11-21 12:57 ` David Wohlferd 2015-11-23 9:56 ` Joseph Myers 2015-11-23 10:04 ` Andrew Haley 0 siblings, 2 replies; 58+ messages in thread From: David Wohlferd @ 2015-11-21 12:57 UTC (permalink / raw) To: Richard Henderson, Jakub Jelinek Cc: Segher Boessenkool, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On 11/20/2015 3:55 PM, David Wohlferd wrote: > On 11/20/2015 8:14 AM, Richard Henderson wrote: >> On 11/20/2015 04:34 PM, Jakub Jelinek wrote: >>> Isn't that going to break too much code though? I mean, e.g. including >>> libgcc... >> >> I don't know. My suspicion is very little. >> >> But that's actually what I'd like to know before we start adjusting >> code in other ways wrt basic asms. > > I can provide a little data here. > > In an effort to gain some perspective, I've been looking at inline asm > usage in the linux kernel (4.3). Clearly this isn't "typical usage," > but it is probably one of the biggest users of inline asm, and likely > has the best justifications for doing so (being an OS and all). > > There are ~5,678 instances of inline asm in use. Of those, ~4,833 are > extended and ~845 are basic. > > I don't have any numbers about how many are top level vs in function, > but let me see what I can do. Ok, the news here is mixed. Of those 845: - Only 50 of them look like top level asm. I was hoping for more. - 457 are in 6 files in the lib/raid6 directory, so there's a bunch that can be done quickly. - That leaves 338 miscellaneous other uses spread throughout some 200 files across multiple platforms. That seems like a lot. Despite the concerns expressed by Jeff about the difficulties in changing from basic to extended, it looks to me like they don't need any conversion (other s/%/%%/). Adding the trailing colon should be sufficient to provide the semantics they have now, which apparently is deemed sufficient. > A quick look at libgcc shows that there are 109 extended and 45 basic > asm statements. I'll see how many end up being top-level, but it > looks like most of them. Of the 45 basic asm statements, only 9 aren't top-level. They all appear to be trivial to change to extended. To sum up: - Some projects (like libgcc) are going to be simple to update. Maybe an hour's work all told. - Some projects (like testsuite) are going to take longer. While the changes are mostly straight-forward, the number of files involved will be a factor. - I took a look at the Mingw-w64 project. It has ~20 non-top level asms, so also pretty simple to update. - But some projects (like linux kernel) are going to be more challenging. Not so much making the changes (although that will take a while) as convincing yourself that the change was harmless and still compiles on all supported platforms. Yes, this represents a very limited sample. And one weighted towards projects that are more likely to use asm. But it does give some sense of the scale. So, what now? While I'd like to take the big step and start kicking out warnings for non-top-level right now, that may be too bold for phase 3. A more modest step for v6 would just provide a way to find them (maybe something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the current behavior as well as the upcoming change. Adding the warning is not something I can do. But I'll create the doc patch once someone confirms that this is the plan. dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-21 12:57 ` David Wohlferd @ 2015-11-23 9:56 ` Joseph Myers 2015-11-23 10:04 ` Andrew Haley 1 sibling, 0 replies; 58+ messages in thread From: Joseph Myers @ 2015-11-23 9:56 UTC (permalink / raw) To: David Wohlferd Cc: Richard Henderson, Jakub Jelinek, Segher Boessenkool, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore [-- Attachment #1: Type: text/plain, Size: 394 bytes --] Note that basic asm is part of the standard C++ syntax. "An asm declaration has the form asm-definition: asm ( string-literal ) ; The asm declaration is conditionally-supported; its meaning is implementation-defined. [ Note: Typically it is used to pass information through the implementation to an assembler. â end note ]" (7.4 [dcl.asm]). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-21 12:57 ` David Wohlferd 2015-11-23 9:56 ` Joseph Myers @ 2015-11-23 10:04 ` Andrew Haley 2015-11-23 20:37 ` Jeff Law 2015-11-23 21:03 ` David Wohlferd 1 sibling, 2 replies; 58+ messages in thread From: Andrew Haley @ 2015-11-23 10:04 UTC (permalink / raw) To: David Wohlferd, Richard Henderson, Jakub Jelinek Cc: Segher Boessenkool, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On 21/11/15 12:56, David Wohlferd wrote: > So, what now? > > While I'd like to take the big step and start kicking out warnings for > non-top-level right now, that may be too bold for phase 3. A more > modest step for v6 would just provide a way to find them (maybe > something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the > current behavior as well as the upcoming change. Warnings would be good. My warning still holds: there are modes of compilation on some machines where you can't clobber all registers without causing reload failures. This is why Jeff didn't fix this in 1999. So, if we really do want to clobber "all" registers in basic asm it'll take a lot of work. Andrew. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-23 10:04 ` Andrew Haley @ 2015-11-23 20:37 ` Jeff Law 2015-11-23 21:36 ` David Wohlferd 2015-11-23 21:03 ` David Wohlferd 1 sibling, 1 reply; 58+ messages in thread From: Jeff Law @ 2015-11-23 20:37 UTC (permalink / raw) To: Andrew Haley, David Wohlferd, Richard Henderson, Jakub Jelinek Cc: Segher Boessenkool, gcc, rth, pinskia, Sandra Loosemore On 11/23/2015 03:04 AM, Andrew Haley wrote: > On 21/11/15 12:56, David Wohlferd wrote: >> So, what now? >> >> While I'd like to take the big step and start kicking out warnings for >> non-top-level right now, that may be too bold for phase 3. A more >> modest step for v6 would just provide a way to find them (maybe >> something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the >> current behavior as well as the upcoming change. > > Warnings would be good. > > My warning still holds: there are modes of compilation on some > machines where you can't clobber all registers without causing reload > failures. This is why Jeff didn't fix this in 1999. So, if we really > do want to clobber "all" registers in basic asm it'll take a lot of > work. Exactly. In retrospect, I probably should have generated more tests for those conditions back in '99. Essentially they'd document a class of problems we'd like to fix over time. I know some have been addressed in various forms, but it hasn't been systematic. My recommendation here is to: 1. Note in the docs what the behaviour should be. This guides where we want to go from an implementation standpoint. I think it'd be fine to *suggest* only using old style asms at the toplevel, but I'm less convinced that mandating that restriction is wise. 2. As we come across failures for adhere to the desired behaviour, fix or document them as known inconsistencies. If we find that some are inherently un-fixable, then we'll need to tighten the docs around those. The more I think about it, I'm just not keen on forcing all those old-style asms to change. jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-23 20:37 ` Jeff Law @ 2015-11-23 21:36 ` David Wohlferd 2015-11-23 21:44 ` Paul_Koning 0 siblings, 1 reply; 58+ messages in thread From: David Wohlferd @ 2015-11-23 21:36 UTC (permalink / raw) To: Jeff Law, Andrew Haley, Richard Henderson, Jakub Jelinek Cc: Segher Boessenkool, gcc, rth, pinskia, Sandra Loosemore On 11/23/2015 12:37 PM, Jeff Law wrote: > On 11/23/2015 03:04 AM, Andrew Haley wrote: >> On 21/11/15 12:56, David Wohlferd wrote: >>> So, what now? >>> >>> While I'd like to take the big step and start kicking out warnings for >>> non-top-level right now, that may be too bold for phase 3. A more >>> modest step for v6 would just provide a way to find them (maybe >>> something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the >>> current behavior as well as the upcoming change. >> >> Warnings would be good. >> >> My warning still holds: there are modes of compilation on some >> machines where you can't clobber all registers without causing reload >> failures. This is why Jeff didn't fix this in 1999. So, if we really >> do want to clobber "all" registers in basic asm it'll take a lot of >> work. > Exactly. In retrospect, I probably should have generated more tests > for those conditions back in '99. Essentially they'd document a class > of problems we'd like to fix over time. > > I know some have been addressed in various forms, but it hasn't been > systematic. > > My recommendation here is to: > > 1. Note in the docs what the behaviour should be. This guides where > we want to go from an implementation standpoint. I think it'd be fine > to *suggest* only using old style asms at the toplevel, but I'm less > convinced that mandating that restriction is wise. I hear your concerns about mandating this. Perhaps starting by providing an option to find them, then (someday) enabling that option by default? > 2. As we come across failures for adhere to the desired behaviour, > fix or document them as known inconsistencies. If we find that some > are inherently un-fixable, then we'll need to tighten the docs around > those. It's your expectation that extended asm won't be sufficient to resolve these issues? > The more I think about it, I'm just not keen on forcing all those > old-style asms to change. If you mean you aren't keen to change them to "clobber all," I'm with you. If you are worried about changing them from basic to extended, what kinds of problems do you foresee? I've been reading a lot of basic asm lately, and it seems to me that most of it would be fine with a simple colon. Certainly no worse than the current behavior. dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-23 21:36 ` David Wohlferd @ 2015-11-23 21:44 ` Paul_Koning 2015-11-24 1:39 ` David Wohlferd 0 siblings, 1 reply; 58+ messages in thread From: Paul_Koning @ 2015-11-23 21:44 UTC (permalink / raw) To: dw; +Cc: law, aph, rth, jakub, segher, gcc, rth, pinskia, sandra > On Nov 23, 2015, at 4:36 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote: > > ... >> The more I think about it, I'm just not keen on forcing all those old-style asms to change. > > If you mean you aren't keen to change them to "clobber all," I'm with you. If you are worried about changing them from basic to extended, what kinds of problems do you foresee? I've been reading a lot of basic asm lately, and it seems to me that most of it would be fine with a simple colon. Certainly no worse than the current behavior. I'm not sure. I have some asm("sync") which I think assume that this means asm("sync"::"memory") paul ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-23 21:44 ` Paul_Koning @ 2015-11-24 1:39 ` David Wohlferd 2015-11-24 2:22 ` Segher Boessenkool 2015-11-24 17:13 ` Paul_Koning 0 siblings, 2 replies; 58+ messages in thread From: David Wohlferd @ 2015-11-24 1:39 UTC (permalink / raw) To: Paul_Koning; +Cc: law, aph, rth, jakub, segher, gcc, rth, pinskia, sandra On 11/23/2015 1:44 PM, Paul_Koning@Dell.com wrote: >> On Nov 23, 2015, at 4:36 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote: >> >> ... >>> The more I think about it, I'm just not keen on forcing all those old-style asms to change. >> If you mean you aren't keen to change them to "clobber all," I'm with you. If you are worried about changing them from basic to extended, what kinds of problems do you foresee? I've been reading a lot of basic asm lately, and it seems to me that most of it would be fine with a simple colon. Certainly no worse than the current behavior. > I'm not sure. I have some asm("sync") which I think assume that this means asm("sync"::"memory") Another excellent reason to nudge people towards using extended asm. If you saw asm("sync":::"memory"), you would *know* what it did, without having to read the docs (which don't say anyway). I'm pretty confident that asm("") doesn't clobber memory on i386, but maybe that behavior is platform-specific. Since i386 doesn't have "sync", I assume you are on something else? If you have a chance to experiment, I'd love confirmation from other platforms that asm("blah") is the same as asm("blah":). Feel free to email me off list to discuss. dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-24 1:39 ` David Wohlferd @ 2015-11-24 2:22 ` Segher Boessenkool 2015-11-24 4:48 ` Jeff Law 2015-11-24 17:13 ` Paul_Koning 1 sibling, 1 reply; 58+ messages in thread From: Segher Boessenkool @ 2015-11-24 2:22 UTC (permalink / raw) To: David Wohlferd Cc: Paul_Koning, law, aph, rth, jakub, gcc, rth, pinskia, sandra On Mon, Nov 23, 2015 at 05:39:17PM -0800, David Wohlferd wrote: > On 11/23/2015 1:44 PM, Paul_Koning@Dell.com wrote: > >>On Nov 23, 2015, at 4:36 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote: > >> > >>... > >>>The more I think about it, I'm just not keen on forcing all those > >>>old-style asms to change. > >>If you mean you aren't keen to change them to "clobber all," I'm with > >>you. If you are worried about changing them from basic to extended, what > >>kinds of problems do you foresee? I've been reading a lot of basic asm > >>lately, and it seems to me that most of it would be fine with a simple > >>colon. Certainly no worse than the current behavior. > >I'm not sure. I have some asm("sync") which I think assume that this > >means asm("sync"::"memory") > > Another excellent reason to nudge people towards using extended asm. If > you saw asm("sync":::"memory"), you would *know* what it did, without > having to read the docs (which don't say anyway). > > I'm pretty confident that asm("") doesn't clobber memory on i386, but > maybe that behavior is platform-specific. Since i386 doesn't have > "sync", I assume you are on something else? > > If you have a chance to experiment, I'd love confirmation from other > platforms that asm("blah") is the same as asm("blah":). Feel free to > email me off list to discuss. The extended asm one is "asm_operands", the basic asm one is "asm_input". There are places where those are handled differently. If any of that matters, who knows. Here is a test that shows that on at least PowerPC the basic asm is identical to the extended asm without clobber (compile with -O2 -S and -fno-ipa-icf if you want to have it easier to read). In this case, the basic asm is treated as not clobbering memory at the tree level already, before expanding to RTL. Segher === int a; void ext_m(void) { int t = a; a = 42; asm("lolz" : : : "memory"); a = t; } void ext(void) { int t = a; a = 42; asm("lolz" :); a = t; } void bas(void) { int t = a; a = 42; asm("lolz"); a = t; } === PowerPC output (-m32, redacted): ext_m: lis 9,a@ha li 8,42 lwz 10,a@l(9) stw 8,a@l(9) lolz stw 10,a@l(9) blr ext: lolz blr bas: lolz blr ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-24 2:22 ` Segher Boessenkool @ 2015-11-24 4:48 ` Jeff Law 2015-11-24 5:12 ` Segher Boessenkool 0 siblings, 1 reply; 58+ messages in thread From: Jeff Law @ 2015-11-24 4:48 UTC (permalink / raw) To: Segher Boessenkool, David Wohlferd Cc: Paul_Koning, aph, rth, jakub, gcc, rth, pinskia, sandra On 11/23/2015 07:22 PM, Segher Boessenkool wrote: > > Here is a test that shows that on at least PowerPC the basic asm is > identical to the extended asm without clobber (compile with -O2 -S and > -fno-ipa-icf if you want to have it easier to read). In this case, > the basic asm is treated as not clobbering memory at the tree level > already, before expanding to RTL. And that IMHO, ought to be considered a bug. Jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-24 4:48 ` Jeff Law @ 2015-11-24 5:12 ` Segher Boessenkool 2015-11-24 5:25 ` Jeff Law 0 siblings, 1 reply; 58+ messages in thread From: Segher Boessenkool @ 2015-11-24 5:12 UTC (permalink / raw) To: Jeff Law Cc: David Wohlferd, Paul_Koning, aph, rth, jakub, gcc, rth, pinskia, sandra On Mon, Nov 23, 2015 at 09:48:42PM -0700, Jeff Law wrote: > On 11/23/2015 07:22 PM, Segher Boessenkool wrote: > > > >Here is a test that shows that on at least PowerPC the basic asm is > >identical to the extended asm without clobber (compile with -O2 -S and > >-fno-ipa-icf if you want to have it easier to read). In this case, > >the basic asm is treated as not clobbering memory at the tree level > >already, before expanding to RTL. > And that IMHO, ought to be considered a bug. I agree. Almost everyone does, as far as I can see. The question is if we want to retain this functionality. No one has depended on this in a long time -- they couldn't, it has been broken since forever -- and there is another mechanism that does reliably give this functionality (extended asm). The first pass that goes wrong for this testcase is fre2, fwiw. Segher ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-24 5:12 ` Segher Boessenkool @ 2015-11-24 5:25 ` Jeff Law 0 siblings, 0 replies; 58+ messages in thread From: Jeff Law @ 2015-11-24 5:25 UTC (permalink / raw) To: Segher Boessenkool Cc: David Wohlferd, Paul_Koning, aph, rth, jakub, gcc, rth, pinskia, sandra On 11/23/2015 10:12 PM, Segher Boessenkool wrote: > On Mon, Nov 23, 2015 at 09:48:42PM -0700, Jeff Law wrote: >> On 11/23/2015 07:22 PM, Segher Boessenkool wrote: >>> >>> Here is a test that shows that on at least PowerPC the basic asm is >>> identical to the extended asm without clobber (compile with -O2 -S and >>> -fno-ipa-icf if you want to have it easier to read). In this case, >>> the basic asm is treated as not clobbering memory at the tree level >>> already, before expanding to RTL. >> And that IMHO, ought to be considered a bug. > > I agree. Almost everyone does, as far as I can see. > > The question is if we want to retain this functionality. No one has > depended on this in a long time -- they couldn't, it has been broken > since forever -- and there is another mechanism that does reliably > give this functionality (extended asm). > > The first pass that goes wrong for this testcase is fre2, fwiw. I think that's the wrong way to look at things -- it's not that nobody is depending on this behaviour, it's nobody has had a problem due to this bug. I've seen some amazing things through the years where you'd think there's absolutely no way they could work -- but they did for a long time with nobody noticing some absolutely horridly wrong code, that when tickled just right would wreck havoc. So again, I would suggest we document the desired behaviour and work towards fixing any deviations from that behaviour. jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-24 1:39 ` David Wohlferd 2015-11-24 2:22 ` Segher Boessenkool @ 2015-11-24 17:13 ` Paul_Koning 2015-11-24 17:49 ` Ian Lance Taylor 2015-11-25 2:11 ` David Wohlferd 1 sibling, 2 replies; 58+ messages in thread From: Paul_Koning @ 2015-11-24 17:13 UTC (permalink / raw) To: dw; +Cc: gcc > On Nov 23, 2015, at 8:39 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote: > > On 11/23/2015 1:44 PM, Paul_Koning@Dell.com wrote: >>> On Nov 23, 2015, at 4:36 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote: >>> >>> ... >>>> The more I think about it, I'm just not keen on forcing all those old-style asms to change. >>> If you mean you aren't keen to change them to "clobber all," I'm with you. If you are worried about changing them from basic to extended, what kinds of problems do you foresee? I've been reading a lot of basic asm lately, and it seems to me that most of it would be fine with a simple colon. Certainly no worse than the current behavior. >> I'm not sure. I have some asm("sync") which I think assume that this means asm("sync"::"memory") > > Another excellent reason to nudge people towards using extended asm. If you saw asm("sync":::"memory"), you would *know* what it did, without having to read the docs (which don't say anyway). > > I'm pretty confident that asm("") doesn't clobber memory on i386, but maybe that behavior is platform-specific. Since i386 doesn't have "sync", I assume you are on something else? Yes, MIPS. > > If you have a chance to experiment, I'd love confirmation from other platforms that asm("blah") is the same as asm("blah":). Feel free to email me off list to discuss. I'm really concerned with loosening the meaning of basic asm. I wish I could find the documentation that says, or implies, that it is a memory clobber. And/or that it is implicitly volatile. The problem is that it's clear from existing code that this assumption was made, and that defining it otherwise would break such code. For example, the code I quoted clearly won't work if stores are moved across the asm("sync"). Given the ever improving optimizers, these things are time bombs -- code that worked for years might suddenly break when the compiler is upgraded. If such breakage is to be done, it must at least come with a warning (which must default to ON). But I'd prefer to see the more conservative approach (more clobbers) taken. paul ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-24 17:13 ` Paul_Koning @ 2015-11-24 17:49 ` Ian Lance Taylor 2015-11-24 18:00 ` Paul_Koning 2015-11-25 2:11 ` David Wohlferd 1 sibling, 1 reply; 58+ messages in thread From: Ian Lance Taylor @ 2015-11-24 17:49 UTC (permalink / raw) To: Paul_Koning; +Cc: David Wohlferd, GCC Development On Tue, Nov 24, 2015 at 8:58 AM, <Paul_Koning@dell.com> wrote: > > I'm really concerned with loosening the meaning of basic asm. I > wish I could find the documentation that says, or implies, that it > is a memory clobber. And/or that it is implicitly volatile. The volatile one is right there in the current docs. https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm "All basic asm blocks are implicitly volatile." Even back in GCC 2.95.3, the docs say (https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93) "If you write an asm instruction with no outputs, GNU CC will know the instruction has side-effects and will not delete the instruction or move it outside of loops" and "An asm instruction without any operands or clobbers (and "old style" asm) will not be deleted or moved significantly, regardless, unless it is unreachable, the same wasy as if you had written a volatile keyword." However, I'm not aware that basic asm's were ever implicitly memory clobbers. Again, back in GCC 2.95.3: "If your assembler instruction modifies memory in an unpredictable fashion, add `memory' to the list of clobbered registers." Ian ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-24 17:49 ` Ian Lance Taylor @ 2015-11-24 18:00 ` Paul_Koning 0 siblings, 0 replies; 58+ messages in thread From: Paul_Koning @ 2015-11-24 18:00 UTC (permalink / raw) To: iant; +Cc: dw, gcc > On Nov 24, 2015, at 12:49 PM, Ian Lance Taylor <iant@google.com> wrote: > > On Tue, Nov 24, 2015 at 8:58 AM, <Paul_Koning@dell.com> wrote: >> >> I'm really concerned with loosening the meaning of basic asm. I >> wish I could find the documentation that says, or implies, that it >> is a memory clobber. And/or that it is implicitly volatile. > > The volatile one is right there in the current docs. > > https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm > > "All basic asm blocks are implicitly volatile." Ok, that's what I remembered. I reported finding that this was not implemented correctly, some number of versions ago. paul ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-24 17:13 ` Paul_Koning 2015-11-24 17:49 ` Ian Lance Taylor @ 2015-11-25 2:11 ` David Wohlferd 2015-11-25 9:09 ` Andrew Haley 1 sibling, 1 reply; 58+ messages in thread From: David Wohlferd @ 2015-11-25 2:11 UTC (permalink / raw) To: Paul_Koning; +Cc: gcc, Ian Lance Taylor On 11/24/2015 8:58 AM, Paul_Koning@Dell.com wrote: >> On Nov 23, 2015, at 8:39 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote: >> >> On 11/23/2015 1:44 PM, Paul_Koning@Dell.com wrote: >>>> On Nov 23, 2015, at 4:36 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote: >>>> >>>> ... >>>>> The more I think about it, I'm just not keen on forcing all those old-style asms to change. >>>> If you mean you aren't keen to change them to "clobber all," I'm with you. If you are worried about changing them from basic to extended, what kinds of problems do you foresee? I've been reading a lot of basic asm lately, and it seems to me that most of it would be fine with a simple colon. Certainly no worse than the current behavior. >>> I'm not sure. I have some asm("sync") which I think assume that this means asm("sync"::"memory") >> Another excellent reason to nudge people towards using extended asm. If you saw asm("sync":::"memory"), you would *know* what it did, without having to read the docs (which don't say anyway). >> >> I'm pretty confident that asm("") doesn't clobber memory on i386, but maybe that behavior is platform-specific. Since i386 doesn't have "sync", I assume you are on something else? > Yes, MIPS. >> If you have a chance to experiment, I'd love confirmation from other platforms that asm("blah") is the same as asm("blah":). Feel free to email me off list to discuss. > I'm really concerned with loosening the meaning of basic asm. I wish I could find the documentation that says, or implies, that it is a memory clobber. And/or that it is implicitly volatile. > > The problem is that it's clear from existing code that this assumption was made, and that defining it otherwise would break such code. For example, the code I quoted clearly won't work if stores are moved across the asm("sync"). > > Given the ever improving optimizers, these things are time bombs -- code that worked for years might suddenly break when the compiler is upgraded. > > If such breakage is to be done, it must at least come with a warning (which must default to ON). But I'd prefer to see the more conservative approach (more clobbers) taken. It looks like Ian has already addressed most of your concerns. Just to emphasize one point: The current behavior of basic asm is to NOT clobber memory. So your existing code that performs asm("sync") is already at risk. The 'fix' I am proposing is to give warnings for every use of basic asm inside functions (top-level asm is not a problem). Users should change all such code to use extended so that they can (must) explicitly specify what their asm clobbers (if anything). Armed with this information, the optimizers can do their work safely. And people maintaining the code can finally be clear about what the asm really does. And the code change should be simple. They can get the same "clobber nothing" behavior that basic asm has always performed by simply adding a colon on the end ( asm("sync":) ). Or they can use any of extended asm's features to get different behavior ( asm("sync":::"memory") ). Or to put that another way, correctly written basic asm can be converted to extended by just adding a colon. Incorrect code may require a bit more work. dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-25 2:11 ` David Wohlferd @ 2015-11-25 9:09 ` Andrew Haley 0 siblings, 0 replies; 58+ messages in thread From: Andrew Haley @ 2015-11-25 9:09 UTC (permalink / raw) To: David Wohlferd, Paul_Koning; +Cc: gcc, Ian Lance Taylor On 25/11/15 02:11, David Wohlferd wrote: > The 'fix' I am proposing is to give warnings for every use of basic asm > inside functions (top-level asm is not a problem). I'm not sure that's such a great idea on its own. My suggestion: 1. Clobber memory. 2. Document a rule which says that all registers which are used must be saved and restored. This won't break any existing usages, and is AFAICS entirely in the spirit of what was originally intended and with the ISO C specification. Andrew. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-23 10:04 ` Andrew Haley 2015-11-23 20:37 ` Jeff Law @ 2015-11-23 21:03 ` David Wohlferd 2015-11-24 9:48 ` Andrew Haley 1 sibling, 1 reply; 58+ messages in thread From: David Wohlferd @ 2015-11-23 21:03 UTC (permalink / raw) To: Andrew Haley, Richard Henderson, Jakub Jelinek Cc: Segher Boessenkool, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On 11/23/2015 2:04 AM, Andrew Haley wrote: > On 21/11/15 12:56, David Wohlferd wrote: >> So, what now? >> >> While I'd like to take the big step and start kicking out warnings for >> non-top-level right now, that may be too bold for phase 3. A more >> modest step for v6 would just provide a way to find them (maybe >> something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the >> current behavior as well as the upcoming change. > Warnings would be good. Richard's suggestion was: > I'm suggesting that we don't accept [basic asm] at all inside a function. One must audit the source and make a conscious decision to write asm("bla" : ); instead. Accepting basic asm outside of a function is perfectly ok. I'm really not a compiler-writer, but I've taken a shot at implementing this. While Richard is talking about completely deprecating this feature (a direction I support), I've started by emitting warnings, and by having the warnings disabled by default. This allows people to experiment with the new direction without getting clobbered by it. My intent is something like this: -Wonly-top-basic-asm Warn if basic @code{asm} statements are used inside a function (ie not at file scope/top level). Due to the potential for unsafe optimizations, always use extended instead of basic asm inside functions. This warning is disabled by default and is not enabled by -Wall or -Wextra. I probably won't include the bits about Wall or Wextra in the actual doc patch. They're here more to provoke comments in case someone thinks this behavior should change. I'm open to suggestions about alternate names, too. I've got this working for both c and c++. It doesn't affect other places that use "asm" like "explicit register variables," "asm labels," "extended asm" or "top level basic asm." It is also pleasantly small. As written, it should be useful to find places in current code that are at risk. However (there's always a 'however'), it doesn't correctly handle "naked" functions (ie __attribute__((naked)) ). By definition, naked functions can *only* include basic asm (https://gcc.gnu.org/ml/gcc/2014-05/msg00172.html). So generating a warning for them is incorrect. I'll need help fixing that. I don't know if it is possible from within the parsers (where my current code is being added) to walk back up and get the attributes for the function. I assume not. In that case, I'll need some help finding some place up the call stack where you can. Suggestions welcome. The patch is at http://www.LimeGreenSocks.com/gcc/24414f.zip and includes test code. > My warning still holds: there are modes of compilation on some > machines where you can't clobber all registers without causing reload > failures. This is why Jeff didn't fix this in 1999. So, if we really > do want to clobber "all" registers in basic asm it'll take a lot of > work. I was always reluctant to see this change made. In addition to the issues you mention, I had questions about the impact on the surrounding code. I like Richard's direction much better. We can start with a disabled warning, then upgrade as seems warranted. dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-23 21:03 ` David Wohlferd @ 2015-11-24 9:48 ` Andrew Haley 0 siblings, 0 replies; 58+ messages in thread From: Andrew Haley @ 2015-11-24 9:48 UTC (permalink / raw) To: David Wohlferd, Richard Henderson, Jakub Jelinek Cc: Segher Boessenkool, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On 23/11/15 21:02, David Wohlferd wrote: >> On 11/23/2015 2:04 AM, Andrew Haley wrote: >> > My warning still holds: there are modes of compilation on some >> > machines where you can't clobber all registers without causing reload >> > failures. This is why Jeff didn't fix this in 1999. So, if we really >> > do want to clobber "all" registers in basic asm it'll take a lot of >> > work. > > I was always reluctant to see this change made. In addition to the > issues you mention, I had questions about the impact on the surrounding > code. I like Richard's direction much better. We can start with a > disabled warning, then upgrade as seems warranted. I don't see any problem with unconditionally clobbering memory. Andrew. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 15:30 ` Richard Henderson 2015-11-20 15:34 ` Jakub Jelinek @ 2015-11-20 16:21 ` Segher Boessenkool 2015-11-27 17:45 ` Segher Boessenkool 2 siblings, 0 replies; 58+ messages in thread From: Segher Boessenkool @ 2015-11-20 16:21 UTC (permalink / raw) To: Richard Henderson Cc: David Wohlferd, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote: > >>It seems to me that it would be better to remove the feature, forcing what > >>must be an extremely small number of users to audit and update to extended > >>asm. > > > >Should asm("bla"); then be an extended asm with no input, no outputs, > >no (non-automatic) clobbers? That would be the most straightforward and > >logical semantics, but will it break user code? > > I'm suggesting that we don't accept that at all inside a function. One > must audit the source and make a conscious decision to write asm("bla" : ); > instead. Ah, or excepting asm("bla") and treating it just like asm("bla" : ), but giving a warning? That will get people to migrate at least. > Accepting basic asm outside of a function is perfectly ok, since that's > just a mechanism by which one can inject complete assembly routines into a > C translation unit. Of course. You cannot have extended asm outside of functions at all. Segher ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 15:30 ` Richard Henderson 2015-11-20 15:34 ` Jakub Jelinek 2015-11-20 16:21 ` Segher Boessenkool @ 2015-11-27 17:45 ` Segher Boessenkool 2 siblings, 0 replies; 58+ messages in thread From: Segher Boessenkool @ 2015-11-27 17:45 UTC (permalink / raw) To: Richard Henderson Cc: David Wohlferd, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote: > On 11/20/2015 04:20 PM, Segher Boessenkool wrote: > >Should asm("bla"); then be an extended asm with no input, no outputs, > >no (non-automatic) clobbers? That would be the most straightforward and > >logical semantics, but will it break user code? > > I'm suggesting that we don't accept that at all inside a function. One > must audit the source and make a conscious decision to write asm("bla" : ); > instead. I have now audited all code involving RTL's ASM_INPUT (i.e. the basic asm), and those work identically to zero-operand no-clobber volatile ASM_OPERANDS (i.e., extended asm) everywhere. Well, two exceptions: the mep port does not handle that second form (which can never happen currently), and the ia64 port treats the two forms differently for its placing of stop bits. So as far as RTL is concerned, we do not need to force users' source code changes for transitioning to "no more basic asm". Now looking at what happens before RTL... probably more exciting ;-) Segher ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 13:05 ` Richard Henderson 2015-11-20 15:20 ` Segher Boessenkool @ 2015-11-20 18:24 ` Jeff Law 2015-11-20 19:39 ` Paul_Koning 2015-11-26 10:30 ` Hans-Peter Nilsson 2 siblings, 1 reply; 58+ messages in thread From: Jeff Law @ 2015-11-20 18:24 UTC (permalink / raw) To: Richard Henderson, David Wohlferd, Andrew Haley Cc: Segher Boessenkool, gcc, rth, pinskia, Sandra Loosemore On 11/20/2015 06:05 AM, Richard Henderson wrote: > > I'd be perfectly happy to deprecate and later completely remove basic > asm within functions. > > Because IMO it's essentially useless. It has no inputs, no outputs, and > no way to tell the compiler what machine state has been changed. We can > say that "it clobbers everything", but that's not actually useful, and > quite difficult as you're finding out. And even more difficult to document exactly what happens, largely because the implementation in GCC isn't consistent across passes and there's differences in behaviour that are dependent on the target implementation as well. Unfortunately there's not a single place where we can ensure consistent behaviour, so each pass has had to handle ASMs independently, and I'm pretty sure they all get it wrong to varying degrees. > > It seems to me that it would be better to remove the feature, forcing > what must be an extremely small number of users to audit and update to > extended asm. That might be a little drastic. Though if we want to go this direction, the first step is to deprecate for a major release cycle. It would be interesting to see how much stuff would complain/break. jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 18:24 ` Jeff Law @ 2015-11-20 19:39 ` Paul_Koning 0 siblings, 0 replies; 58+ messages in thread From: Paul_Koning @ 2015-11-20 19:39 UTC (permalink / raw) To: law; +Cc: gcc > On Nov 20, 2015, at 1:24 PM, Jeff Law <law@redhat.com> wrote: > > On 11/20/2015 06:05 AM, Richard Henderson wrote: > >> ... >> It seems to me that it would be better to remove the feature, forcing >> what must be an extremely small number of users to audit and update to >> extended asm. > That might be a little drastic. Though if we want to go this direction, the first step is to deprecate for a major release cycle. It would be interesting to see how much stuff would complain/break. I would expect: a lot. I've seen plenty of people writing asm statements (in small quantities, admittedly) who have never heard of extended asm. paul ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 13:05 ` Richard Henderson 2015-11-20 15:20 ` Segher Boessenkool 2015-11-20 18:24 ` Jeff Law @ 2015-11-26 10:30 ` Hans-Peter Nilsson 2015-11-26 12:35 ` Segher Boessenkool 2 siblings, 1 reply; 58+ messages in thread From: Hans-Peter Nilsson @ 2015-11-26 10:30 UTC (permalink / raw) To: Richard Henderson Cc: David Wohlferd, Andrew Haley, Jeff Law, Segher Boessenkool, gcc, rth, pinskia, Sandra Loosemore On Fri, 20 Nov 2015, Richard Henderson wrote: > I'd be perfectly happy to deprecate and later completely remove basic asm > within functions. We've explictly promised (directed to kernel people IIRC) that the empty basic asm; 'asm ("")', has forward-compatible outlining magic, so people would not have to keep adding ever-new attributes like noinline,noclone to avoid finding their functions "spilling over", so please exclude that. To wit, from extend.texi: @item noinline @cindex @code{noinline} function attribute This function attribute prevents a function from being considered for inlining. @c Don't enumerate the optimizations by name here; we try to be @c future-compatible with this mechanism. If the function does not have side-effects, there are optimizations other than inlining that cause function calls to be optimized away, although the function call is live. To keep such calls from being optimized away, put @smallexample asm (""); @end smallexample @noindent (@pxref{Extended Asm}) in the called function, to serve as a special side-effect. brgds, H-P ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-26 10:30 ` Hans-Peter Nilsson @ 2015-11-26 12:35 ` Segher Boessenkool 2015-11-26 16:26 ` Hans-Peter Nilsson 0 siblings, 1 reply; 58+ messages in thread From: Segher Boessenkool @ 2015-11-26 12:35 UTC (permalink / raw) To: Hans-Peter Nilsson Cc: Richard Henderson, David Wohlferd, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote: > On Fri, 20 Nov 2015, Richard Henderson wrote: > > I'd be perfectly happy to deprecate and later completely remove basic asm > > within functions. > > We've explictly promised (directed to kernel people IIRC) that > the empty basic asm; 'asm ("")', has forward-compatible > outlining magic, so people would not have to keep adding > ever-new attributes like noinline,noclone to avoid finding their > functions "spilling over", so please exclude that. To wit, from > extend.texi: > > @item noinline > @cindex @code{noinline} function attribute > This function attribute prevents a function from being considered for > inlining. > @c Don't enumerate the optimizations by name here; we try to be > @c future-compatible with this mechanism. > If the function does not have side-effects, there are optimizations > other than inlining that cause function calls to be optimized away, > although the function call is live. To keep such calls from being > optimized away, put > @smallexample > asm (""); > @end smallexample > > @noindent > (@pxref{Extended Asm}) in the called function, to serve as a > special > side-effect. Any asm without outputs (including basic asm) is volatile, so it can not be optimised away. Putting an empty asm in a noinline function should always work as you want, it's not because it is basic asm. Segher ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-26 12:35 ` Segher Boessenkool @ 2015-11-26 16:26 ` Hans-Peter Nilsson 2015-11-26 21:54 ` David Wohlferd 0 siblings, 1 reply; 58+ messages in thread From: Hans-Peter Nilsson @ 2015-11-26 16:26 UTC (permalink / raw) To: Segher Boessenkool Cc: Richard Henderson, David Wohlferd, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On Thu, 26 Nov 2015, Segher Boessenkool wrote: > On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote: > > On Fri, 20 Nov 2015, Richard Henderson wrote: > > > I'd be perfectly happy to deprecate and later completely remove basic asm > > > within functions. > > > > We've explictly promised (directed to kernel people IIRC) that > > the empty basic asm; 'asm ("")', has forward-compatible > > outlining magic, so people would not have to keep adding > > ever-new attributes like noinline,noclone to avoid finding their > > functions "spilling over", so please exclude that. To wit, from > > extend.texi: > > > > @item noinline > > @cindex @code{noinline} function attribute > > This function attribute prevents a function from being considered for > > inlining. > > @c Don't enumerate the optimizations by name here; we try to be > > @c future-compatible with this mechanism. > > If the function does not have side-effects, there are optimizations > > other than inlining that cause function calls to be optimized away, > > although the function call is live. To keep such calls from being > > optimized away, put > > @smallexample > > asm (""); > > @end smallexample > > > > @noindent > > (@pxref{Extended Asm}) in the called function, to serve as a > > special > > side-effect. > > Any asm without outputs (including basic asm) is volatile, so it can > not be optimised away. Putting an empty asm in a noinline function > should always work as you want, it's not because it is basic asm. I know, the point is that we've promised the above and we shouldn't back down on this mechanism to instead deprecate and warn about it, as seems to be the direction. This happens to be expressed as a basic asm and was chosen because the right things happen regarding backwards- compatibility. More care has to be taken for forward- compatibility. I'm a bit worried that it still works only because of happenstance. I know what (I hope) you're thinking but it's hard to produce a test-case that fails when a future yet unknown optimization causes "spill-over", but I can imagine a quick return-path seeming inlinable in LTO. brgds, H-P ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-26 16:26 ` Hans-Peter Nilsson @ 2015-11-26 21:54 ` David Wohlferd 2015-11-26 23:39 ` Hans-Peter Nilsson 0 siblings, 1 reply; 58+ messages in thread From: David Wohlferd @ 2015-11-26 21:54 UTC (permalink / raw) To: Hans-Peter Nilsson, Segher Boessenkool Cc: Richard Henderson, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On 11/26/2015 8:26 AM, Hans-Peter Nilsson wrote: > On Thu, 26 Nov 2015, Segher Boessenkool wrote: >> On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote: >>> On Fri, 20 Nov 2015, Richard Henderson wrote: >>>> I'd be perfectly happy to deprecate and later completely remove basic asm >>>> within functions. >>> We've explictly promised (directed to kernel people IIRC) that >>> the empty basic asm; 'asm ("")', has forward-compatible >>> outlining magic, so people would not have to keep adding >>> ever-new attributes like noinline,noclone to avoid finding their >>> functions "spilling over", so please exclude that. To wit, from >>> extend.texi: >>> >>> @item noinline >>> @cindex @code{noinline} function attribute >>> This function attribute prevents a function from being considered for >>> inlining. >>> @c Don't enumerate the optimizations by name here; we try to be >>> @c future-compatible with this mechanism. >>> If the function does not have side-effects, there are optimizations >>> other than inlining that cause function calls to be optimized away, >>> although the function call is live. To keep such calls from being >>> optimized away, put >>> @smallexample >>> asm (""); >>> @end smallexample >>> >>> @noindent >>> (@pxref{Extended Asm}) in the called function, to serve as a >>> special >>> side-effect. >> Any asm without outputs (including basic asm) is volatile, so it can >> not be optimised away. Putting an empty asm in a noinline function >> should always work as you want, it's not because it is basic asm. > I know, the point is that we've promised the above and we > shouldn't back down on this mechanism to instead deprecate and > warn about it, as seems to be the direction. That is indeed the direction I am heading unless someone stops me. I was not aware of this magic. Thanks for pointing it out. To be clear, wouldn't asm("":) have the same effect? Since we have committed to this, we don't want to change it lightly. Also, looking at existing inline asm, this is probably one of the most common uses. Allowing this exception will probably ease the migration, even if it makes the docs a little clunkier. So how about this: 1) Change the docs to say asm("":), so future coders will do "the right thing." 2) Allow the exception for v6. 3) Re-evaluate if-and-when we continue with the deprecation process. > This happens to be expressed as a basic asm and was chosen > because the right things happen regarding backwards- > compatibility. More care has to be taken for forward- > compatibility. I'm a bit worried that it still works only > because of happenstance. > > I know what (I hope) you're thinking but it's hard to produce a > test-case that fails when a future yet unknown optimization > causes "spill-over", but I can imagine a quick return-path > seeming inlinable in LTO. dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-26 21:54 ` David Wohlferd @ 2015-11-26 23:39 ` Hans-Peter Nilsson 2015-11-27 1:04 ` David Wohlferd 0 siblings, 1 reply; 58+ messages in thread From: Hans-Peter Nilsson @ 2015-11-26 23:39 UTC (permalink / raw) To: David Wohlferd Cc: Segher Boessenkool, Richard Henderson, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore On Thu, 26 Nov 2015, David Wohlferd wrote: > On 11/26/2015 8:26 AM, Hans-Peter Nilsson wrote: > > On Thu, 26 Nov 2015, Segher Boessenkool wrote: > > > On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote: > > > > @item noinline ... > > > > asm (""); ... > > I know, the point is that we've promised the above and we > > shouldn't back down on this mechanism to instead deprecate and > > warn about it, as seems to be the direction. > > That is indeed the direction I am heading unless someone stops me. > > I was not aware of this magic. Thanks for pointing it out. To be clear, > wouldn't asm("":) have the same effect? That does not matter. It'd require source-code changes to users' code. BTW, does that syntax work for really olden gcc (say 2.95 era)? Either way, we promised 'asm("")'. I'm pretty sure the empty string is identifiable. Whatever happens to register-clobbering effects (wrt. this being expressed as a "basic asm") is less interesting; it can be made the same as 'asm("":)' whenever any actual-basic-asm-deprecation is complete, IIUC. I have no issue with any *actual* basic asm changes. That might be a good idea, modulo standards issues of course (IIUC it's optional in *some* ISO/ANSI standards, but better check all applicable versions). > Since we have committed to this, we don't want to change it lightly. Right. I don't understand why we couldn't except this particular thing from actual-basic-asm-deprecation. FWIW, I see the point in making sure 'asm("":)' does the same, for syntax consistency, but I wouldn't call that syntax "the right thing". brgds, H-P ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-26 23:39 ` Hans-Peter Nilsson @ 2015-11-27 1:04 ` David Wohlferd 0 siblings, 0 replies; 58+ messages in thread From: David Wohlferd @ 2015-11-27 1:04 UTC (permalink / raw) To: Hans-Peter Nilsson Cc: Segher Boessenkool, Richard Henderson, Andrew Haley, Jeff Law, gcc, rth, pinskia, Sandra Loosemore >> To be clear, wouldn't asm("":) have the same effect? > > That does not matter. It'd require source-code changes to > users' code. My suggestion was to allow the exception to the "basic asm in a function" warning, but change the docs to show using the new syntax. This does not require any user code change. But it kinda does matter whether or not it will work. Copy/pasting my suggestion: 1) Change the docs to say asm("":), so future coders will do "the right thing." 2) Allow the exception for v6. 3) Re-evaluate if-and-when we continue with the deprecation process. It may not be clear from this, but I don't expect step 3 to happen until at least v7. And saying "the right thing" may be a bit flip. But if deprecating basic asm is the path we are choosing, then telling users to use this syntax is how the text should read. Assuming it works. > BTW, does that syntax work for really olden gcc > (say 2.95 era)? The oldest docs I can find are 2.95.3, and they talk about the extended asm syntax, so I assume so: https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93 > Either way, we promised 'asm("")'. I'm pretty > sure the empty string is identifiable. It is. I've already updated my code to support this exception. dw ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: basic asm and memory clobbers 2015-11-20 11:14 ` Andrew Haley 2015-11-20 12:38 ` David Wohlferd @ 2015-11-20 16:41 ` Jeff Law 1 sibling, 0 replies; 58+ messages in thread From: Jeff Law @ 2015-11-20 16:41 UTC (permalink / raw) To: Andrew Haley, David Wohlferd, Segher Boessenkool Cc: gcc, rth, pinskia, Sandra Loosemore On 11/20/2015 04:14 AM, Andrew Haley wrote: > On 20/11/15 10:37, David Wohlferd wrote: >> The intent for 24414 is to change basic asm such that it will become >> (quoting jeff) "an opaque blob that read/write/clobber any register or >> memory location." Such being the case, "memory" is not sufficient: >> >> #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11", >> "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory" > > Hmm. I would not be at all surprised to see this cause reload > failures. You certainly shouldn't clobber the frame pointer on > any machine which needs one. Right. It'll cause other issues as well. It's the only reason why I didn't change the code internally to stomp every hard register back in 1999. jeff ^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~2015-11-27 17:45 UTC | newest] Thread overview: 58+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-09 0:10 basic asm and memory clobbers David Wohlferd 2015-11-09 9:32 ` Segher Boessenkool 2015-11-16 1:23 ` David Wohlferd 2015-11-16 21:29 ` Jeff Law 2015-11-17 5:56 ` David Wohlferd 2015-11-17 9:27 ` Andrew Haley 2015-11-17 21:31 ` Jeff Law 2015-11-17 22:07 ` Andrew Pinski 2015-11-18 22:04 ` Jeff Law 2015-11-18 1:28 ` Segher Boessenkool 2015-11-18 22:08 ` Jeff Law 2015-11-20 1:24 ` David Wohlferd 2015-11-20 1:53 ` Sandra Loosemore 2015-11-22 5:09 ` David Wohlferd 2015-11-20 3:14 ` Segher Boessenkool 2015-11-20 10:45 ` David Wohlferd 2015-11-20 14:56 ` Segher Boessenkool 2015-11-20 20:01 ` Jeff Law 2015-11-20 22:07 ` Paul_Koning 2015-11-20 10:17 ` Andrew Haley 2015-11-20 10:38 ` David Wohlferd 2015-11-20 11:14 ` Andrew Haley 2015-11-20 12:38 ` David Wohlferd 2015-11-20 13:05 ` Richard Henderson 2015-11-20 15:20 ` Segher Boessenkool 2015-11-20 15:30 ` Richard Henderson 2015-11-20 15:34 ` Jakub Jelinek 2015-11-20 16:14 ` Richard Henderson 2015-11-20 23:56 ` David Wohlferd 2015-11-21 12:57 ` David Wohlferd 2015-11-23 9:56 ` Joseph Myers 2015-11-23 10:04 ` Andrew Haley 2015-11-23 20:37 ` Jeff Law 2015-11-23 21:36 ` David Wohlferd 2015-11-23 21:44 ` Paul_Koning 2015-11-24 1:39 ` David Wohlferd 2015-11-24 2:22 ` Segher Boessenkool 2015-11-24 4:48 ` Jeff Law 2015-11-24 5:12 ` Segher Boessenkool 2015-11-24 5:25 ` Jeff Law 2015-11-24 17:13 ` Paul_Koning 2015-11-24 17:49 ` Ian Lance Taylor 2015-11-24 18:00 ` Paul_Koning 2015-11-25 2:11 ` David Wohlferd 2015-11-25 9:09 ` Andrew Haley 2015-11-23 21:03 ` David Wohlferd 2015-11-24 9:48 ` Andrew Haley 2015-11-20 16:21 ` Segher Boessenkool 2015-11-27 17:45 ` Segher Boessenkool 2015-11-20 18:24 ` Jeff Law 2015-11-20 19:39 ` Paul_Koning 2015-11-26 10:30 ` Hans-Peter Nilsson 2015-11-26 12:35 ` Segher Boessenkool 2015-11-26 16:26 ` Hans-Peter Nilsson 2015-11-26 21:54 ` David Wohlferd 2015-11-26 23:39 ` Hans-Peter Nilsson 2015-11-27 1:04 ` David Wohlferd 2015-11-20 16:41 ` Jeff Law
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).