[patch tree-optimization 1/2]: Branch-cost optimizations

Jeff Law law@redhat.com
Tue Nov 8 19:26:00 GMT 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/07/11 15:42, Richard Guenther wrote:
> 
> IIRC valgrind even offers simple branch predictor simulation - well
> predicted branches tend to be cheap.
It does.  The predictor is based on processors that are 5-7 years old.
  I don't generally look closely at the prediction stuff.

Removing even well predicted branches is profitable as they consume
resources within the hardware predictor mechanisms.  Obviously we get
more benefit by removing difficult to predict branches.

As I've mentioned to Kai, raw insn & branch counts from valgrind are
useful, but are just a piece of the puzzle.  For example, when
speculating, we'll obviously increase the insn count, but it may be
the case that there's sufficient processor resources to hide the cost
of the speculated code.  The same can often happen with if-conversion.
 We may execute more insns, but eliminate costly branches.

Even with its faults, the valgrind results are helpful; just like any
other tool we have to understand its limitations.


> 
> The question on which side to lean for canonicalization before such
> lowering remains though (a few years back I thought of an enabling
> pass that would agressively transform IL in either way, but that's
> of course not going to be cheap). If we'd have SSA names for all
> predicates then the if statments plus edges would trivially map to
> &&s and ||s, so maybe canonicalization in either way wouldn't be
> too important in that case.  Now there's quite some fallout with
> that change though.
As you say, it's something we've never really decided which is best.
Exposing a name for every predicate has value.  But exposing it in the
IL has, at least in the past, generally resulted in worse code.  So
the question becomes can we fix things so that exposing the name
doesn't regress the code, or can we expose a name, even if it's not
reflected in the IL.

jeff


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOuYBhAAoJEBRtltQi2kC7pSwH/3Tpbm3ayZAtg0Swef/DOI6M
miLlO5ZZXoqwJdiU0QFccI6zYSq7Y/JvTHhxYZIQ0QlOO+n2YUGdWk4FwGSRHGs4
kZk1ICRPdDKCXWvvM9gKQWYR9vM0VJql1VAD1TQP465g2af5kqaH7vM+nzCVGEGp
0uFlzx58wqozZnIldNyHqrtlnRJtvSdLFDH9Pduv6IL37NcBrJjzHR9kmObxu4uL
zS9JdiFoODfQRAOOlr3POqL2u54wJA8rstsPJLBns+MsGe5HTZ1GqxyKgs3bgIsk
m60GML1satgkQPfI6XJsWeTYW0uLDKAwtQGsmUT+h3Mnl9WNO/cr2GwHUA4wwzw=
=KZkC
-----END PGP SIGNATURE-----



More information about the Gcc-patches mailing list