Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

Linus Torvalds
2009-01-20T21:55:38Z

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 thatt 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 hug 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