This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: basic asm and memory clobbers


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]