GCC 4.3.2. Maybe i missed something obvious?
The typical use case of restrict is to tell it that multiple given
arrays are independent and then give the loop optimizer
more freedom to handle expressions in the loop that
accesses these arrays.
Since there are no loops in the list functions
On Wed, Jan 21, 2009 at 09:54:02AM +0100, Andi Kleen wrote:
GCC 4.3.2. Maybe i missed something obvious?
The typical use case of restrict is to tell it that multiple given
arrays are independent and then give the loop optimizer
more freedom to handle expressions in the loop that
accesses
On Wed, Jan 21, 2009 at 10:20:49AM +0100, Andi Kleen wrote:
On Wed, Jan 21, 2009 at 09:52:08AM +0100, Nick Piggin wrote:
On Wed, Jan 21, 2009 at 09:54:02AM +0100, Andi Kleen wrote:
GCC 4.3.2. Maybe i missed something obvious?
The typical use case of restrict is to tell it that
The point is that the compiler is then free to do it. If things
slow down after the compiler gets *more* information, then that
is a problem with the compiler heuristics rather than the
information we give it.
The point was the -Os disables it typically then.
(not always, compiler heuristics
On Tue, 2009-01-20 at 13:38 +0100, Ingo Molnar wrote:
* Nick Piggin npig...@suse.de wrote:
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,
Ingo Molnar wrote:
Hm, GCC uses __restrict__, right?
I'm wondering whether there's any internal tie-up between alias analysis
and the __restrict__ keyword - so if we turn off aliasing optimizations
the __restrict__ keyword's optimizations are turned off as well.
Actually I suspect that
On Tue, Jan 20, 2009 at 08:01:52AM +1100, Linus Torvalds wrote:
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'.
The problem with 'restrict' is that almost nobody uses it, and it does
Also gcc traditionally didn't do a very good job using it (this
might be better in the very latest versions). At least some of the 3.x
often discarded this information.
automatically. But it should work well as a way to
Andi Kleen wrote:
On Sun, Jan 11, 2009 at 04:21:03PM -0800, Linus Torvalds wrote:
On Mon, 12 Jan 2009, Andi Kleen wrote:
so at least least for this case it works. Your case also doesn't work
for me. So it looks like gcc didn't like something you did in your test
program.
I very
On Mon, Jan 12, 2009 at 11:02:17AM -0800, Linus Torvalds wrote:
Something at the back of my mind said aliasing.
$ gcc linus.c -O2 -S ; grep subl linus.s
subl$1624, %esp
$ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
subl$824, %esp
That's with
Andi Kleen wrote:
On Mon, Jan 12, 2009 at 11:02:17AM -0800, Linus Torvalds wrote:
Something at the back of my mind said aliasing.
$ gcc linus.c -O2 -S ; grep subl linus.s
subl$1624, %esp
$ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
subl$824, %esp
That's
On Mon, 12 Jan 2009, Andi Kleen wrote:
What I find nonsensical is that -fno-strict-aliasing generates
better code here. Normally one would expect the compiler seeing
more aliases with that option and then be more conservative
regarding any sharing. But it seems to be the other way round
On Mon, 12 Jan 2009, H. Peter Anvin wrote:
This is about storage allocation, not aliases. Storage allocation only
depends on lifetime.
Well, the thing is, code motion does extend life-times, and if you think
you can move stores across each other (even when you can see that they
alias
Linus Torvalds wrote:
On Mon, 12 Jan 2009, Bernd Schmidt wrote:
Something at the back of my mind said aliasing.
$ gcc linus.c -O2 -S ; grep subl linus.s
subl$1624, %esp
$ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
subl$824, %esp
That's with 4.3.2.
On Mon, 12 Jan 2009, Bernd Schmidt wrote:
However, if the compiler chooses to put them into the same stack
location, the RTL-based alias analysis will happily conclude (based on
the differing types) that the reads from A and the writes to B can't
possibly conflict, and some passes may
Linus Torvalds wrote:
This is about storage allocation, not aliases. Storage allocation only
depends on lifetime.
Well, the thing is, code motion does extend life-times, and if you think
you can move stores across each other (even when you can see that they
alias statically) due to
Linus Torvalds wrote:
But you'll need some background to it:
You paint a somewhat one-sided picture bordering on FUD.
Type-based aliasing is _stupid_.
Type-based aliasing is simply an application of the language definition,
and depending on the compiled application and/or target architecture,
On Mon, 12 Jan 2009, Bernd Schmidt wrote:
Too lazy to construct one myself, I googled for examples, and here's a
trivial one that shows how it affects the ability of the compiler to
eliminate memory references:
Do you really think this is realistic or even relevant?
The fact is
(a)
On Sun, 2009-01-11 at 21:14 +0100, Andi Kleen wrote:
On the other hand (my personal opinion, not shared by everyone) is
that the ioctl switch stack issue is mostly only a problem with 4K
stacks and in the rare cases when I still run 32bit kernels
I never set that option because I consider
On Sun, 11 Jan 2009, Andi Kleen wrote:
Was -- i think that got fixed in gcc. But again only in newer versions.
I doubt it. People have said that about a million times, it has never
gotten fixed, and I've never seen any actual proof.
I think that what got fixed was that gcc now at least
20 matches
Mail list logo
