This is the mail archive of the
mailing list for the GCC project.
Re: basic asm and memory clobbers
- From: David Wohlferd <dw at LimeGreenSocks dot com>
- To: Richard Henderson <rth at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, Andrew Haley <aph at redhat dot com>, Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, rth at gcc dot gnu dot org, pinskia at gcc dot gnu dot org, Sandra Loosemore <sandra at codesourcery dot com>
- Date: Sat, 21 Nov 2015 04:56:35 -0800
- Subject: Re: basic asm and memory clobbers
- Authentication-results: sourceware.org; auth=none
- References: <564AC155 dot 4040601 at LimeGreenSocks dot com> <564B9CB1 dot 1060001 at redhat dot com> <564E762B dot 6070705 at LimeGreenSocks dot com> <564EF338 dot 4030703 at redhat dot com> <564EF7FF dot 1070107 at LimeGreenSocks dot com> <564F008B dot 8040703 at redhat dot com> <564F1436 dot 2060005 at LimeGreenSocks dot com> <564F1A7D dot 9050607 at redhat dot com> <20151120152039 dot GA15922 at gate dot crashing dot org> <564F3C6E dot 5010908 at redhat dot com> <20151120153431 dot GJ5675 at tucnak dot redhat dot com> <564F46CF dot 2030403 at redhat dot com> <564FB2ED dot 70803 at LimeGreenSocks dot com>
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
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
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.