From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement
Date: Mon, 19 Jan 2009 21:03:55 UTC
Message-ID: <fa.iiYg1jK55WYGnpm2kr4iJCAhSQk@ifi.uio.no>

On Mon, 19 Jan 2009, Nick Piggin wrote:
>
> I want to know what is the problem with the restrict keyword?
> I'm sure I've read Linus ranting about how bad it is in the
> past...

No, I don't think I've ranted about 'restrict'. I think it's a reasonable
solution for performance-critical code, and unlike the whole type-aliasing
model, it actually works for the _sane_ cases (ie doing some operation
over two arrays of the same type, and letting the compiler know that it
can access the arrays without fearing that writing to one would affect
reading from the other).

The problem with 'restrict' is that almost nobody uses it, and it does
obviously require programmer input rather than the compiler doing it
automatically. But it should work well as a way to get Fortran-like
performance from HPC workloads written in C - which is where most of the
people are who really want the alias analysis.

> it seems like a nice opt-in thing that can be used where the aliases are
> verified and the code is particularly performance critical...

Yes. I think we could use it in the kernel, although I'm not sure how many
cases we would ever find where we really care.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement
Date: Tue, 20 Jan 2009 21:55:48 UTC
Message-ID: <fa.ak2RiKMvyk4m7wZCB+3n8oNS9fQ@ifi.uio.no>

On Tue, 20 Jan 2009, Ingo Molnar wrote:
>
> (Different-type pointer uses are a common pattern: we have a lot of places
> where we have pointers to structures with different types so
> strict-aliasing optimization opportunities apply quite broadly already.)

Yes and no.

It's true that the kernel in general uses mostly pointers through
structures that can help the type-based thing.

However, the most common and important cases are actually the very same
structures. In particular, things like <linux/list.h>. Same "struct list",
often embedded into another case of the same struct.

And that's where "restrict" can actually help. It might be interesting to
see, for example, if it makes any difference to add a "restrict" qualifier
to the "new" pointer in __list_add(). That might give the compiler the
ability to schedule the stores to next->prev and prev->next differently,
and maybe it could matter?

It probably is not noticeable. The big reason for wanting to do alias
analysis tends to not be that kind of code at all, but the cases where
you can do much bigger simplifications, or on in-order machines where you
really want to hoist things like FP loads early and FP stores late, and
alias analysis (and here type-based is more reasonable) shows that the FP
accesses cannot alias with the integer accesses around it.

In x86, I doubt _any_ amount of alias analysis makes a huge difference (as
long as the compiler at least doesn't think that local variable spills can
alias with anything else). Not enough registers, and generally pretty
aggressively OoO (with alias analysis in hardware) makes for a much less
sensitive platform.

			Linus