[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48163B50.8010608@goop.org>
Date: Mon, 28 Apr 2008 14:02:08 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
Ingo Molnar <mingo@...e.hu>, Jiri Slaby <jirislaby@...il.com>,
David Miller <davem@...emloft.net>, zdenek.kabelac@...il.com,
rjw@...k.pl, paulmck@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
linux-ext4@...r.kernel.org, herbert@...dor.apana.org.au,
penberg@...helsinki.fi, clameter@....com,
linux-kernel@...r.kernel.org, pageexec@...email.hu
Subject: Re: [PATCH 1/1] x86: fix text_poke
Mathieu Desnoyers wrote:
> Markers, with immediate values, only clobbers the eax register and the
> ZF. It does not restrain inlining nor loop unrolling. It also requires
> gcc to leave the variables in which the marker is interested "live".
That in itself is pretty significant. If that value would otherwise be
constant folded or strength-reduced away, you're putting a big
limitation on what the compiler can do. The mere fact that its
necessary to do something to preserve many values shows how much the
compiler transforms the code away from what's in the source, and
specifically referencing otherwise unused intermediates inhibits that.
In other words, if you weren't preventing optimisations, you wouldn't
need to preserve values as much, because the optimiser wouldn't be
getting rid of them. If you need to preserve lots of values, you're
necessarily preventing the optimiser from doing its job.
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists