This is the mail archive of the
mailing list for the GCC project.
Re: Some optimization thoughts (and thanks!)
- To: Jan Hubicka <jh at suse dot cz>
- Subject: Re: Some optimization thoughts (and thanks!)
- From: Tom Leete <tleete at mountain dot net>
- Date: Wed, 02 May 2001 17:55:47 -0400
- CC: At150bogomips at aol dot com, gcc at gcc dot gnu dot org
- References: <20010502163209.A15825@atrey.karlin.mff.cuni.cz>
Jan Hubicka wrote:
> > * When branches are expensive, it might be reasonable to translate if
> > statements with multiple conditions into merged condition and a single
> > branch rather than multiple branches. E.g., "if ((A==N) && (B==M))"
> > might be translated into "XOR Temp1 A N; XOR Temp2 B M; OR Temp1 Temp2
> > Temp1; BNEZ Temp1 L3; #branch over conditional code" rather than "XOR
> > Temp1 A N; BNEZ Temp1 L3; #branch over second condition test and
> > conditional code\\ XOR Temp1 B M; BNEZ Temp1 L3;" Removing a branch
> > might increase modality of the branch and decrease branch history
> > table aliasing, improving branch prediction. Such prediction
> > improvement might compensate for the overhead of performing both tests
> > in all cases. (This is what happened in a test case using a pair of
> > comparisons of a random number and a constant, at least performance
> > improved on an x86-based system.)
> I've implemented this last month so I will try to contribute that
> once I find time to polish thinks and test the code.
Operator && is a sequence point, and it short-circuits. If (A==N) evaluates
false, (B==M) must not be evaluated and none of its side-effects occur. IMO
that includes clobbering the processor flags.
Other constructions can give the effect you want.
The Daemons lurk and are dumb. -- Emerson