Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 17 Mar 2022 15:51:28 -0700 | Subject | Re: [PATCH v5] x86: use builtins to read eflags |
| |
On Thu, Mar 17, 2022 at 2:45 PM Bill Wendling <morbo@google.com> wrote: > > I'm NOT saying that it WILL change or that it SHOULD change. I'm also > not saying that your concern isn't justified. What I am saying is that > unless you're using a compiler feature that's DEFINED as having a > certain effect, then you are not using that feature correctly, > regardless of how it's acted in the past. And it has the potential to > bite you in the ass sooner or later. We've all seen such things happen > before.
So I think most of inline asm constraints are fairly well defined. Certainly "memory" clobbers are.
The unfortunate exception to this is, I think, "volatile". It has always had somewhat undefined semantics (iirc originally gcc talked about it not being "moved significantly" etc), and it ends up getting mixed reasons for existing.
The *natural* semantics would be to literally make it have the same rules as volatile data accesses: something like "'volatile' marks the asm as having visible side effects in the virtual machine".
So I think natural semantics for "asm volatile" - and the ones that would be simple to document - would literally be to compare it to those volatile memory accesses, and say that it can't be optimized away, and it's ordered wrt other volatile operations (whether volatile data accesses or other volatile asm instructions).
But that is, afaik, not what it ever did, so it always had somewhat random semantics, the main being "it can't be removed even if its outputs are never used". So the "cannot be optimized away" ends up being the central part of the definition, but without the conceptual sense.
And then we in the kernel have then also co-opted 'asm volatile' to just fix some compiler bugs, so we end up using "asm volatile goto" because of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
although *that* particular issue is probably historical now that we require more modern compiler versions.
I still think that from a sanity standpoint, it would be good to actually strengthen the semantics of "asm volatile" to literally act as - and be ordered with - volatile memory accesses.
But I guess that's water under the bridge.
Linus
| |