[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1276174140.2077.261.camel@twins>
Date: Thu, 10 Jun 2010 14:49:00 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Jason Baron <jbaron@...hat.com>
Cc: linux-kernel@...r.kernel.org, mingo@...e.hu,
mathieu.desnoyers@...ymtl.ca, hpa@...or.com, tglx@...utronix.de,
rostedt@...dmis.org, andi@...stfloor.org, roland@...hat.com,
rth@...hat.com, mhiramat@...hat.com, fweisbec@...il.com,
avi@...hat.com, davem@...emloft.net, vgoyal@...hat.com,
sam@...nborg.org
Subject: Re: [PATCH 13/13] jump label v9: add docs
On Wed, 2010-06-09 at 17:39 -0400, Jason Baron wrote:
> +The optimization depends on !CC_OPTIMIZE_FOR_SIZE. When CC_OPTIMIZE_FOR_SIZE is
> +set, gcc does not always out of line the not taken label path in the same way
> +that the "if unlikely()" paths are made out of line. Thus, with
> +CC_OPTIMIZE_FOR_SIZE set, this optimization is not always optimal. This may be
> +solved in subsequent gcc versions, that allow us to move labels out of line,
> +while still optimizing for size. In the case of !CC_OPTIMIZE_FOR_SIZE this
> +optimization is seen on high level benchmarks such as tbench where I can get
> +~1-2% higher throughput. In addition we are within .5% of the performance of no
> +tracepoints compiled in at all.
But does it generate invalid code for whatever -f flag triggers this
(-fno-reorder-blocks ?)
--
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