Re: [PATCH] Optimize "a || b" into "(a | b) != 0"

[Roger Sayle <roger at eyesopen dot com>]

Hi Jan,
> one of problem I see whit this idea is that it may result into expensive
> expression when chained (imagine long sequence of a || b || c || d || e || f).

As I've mentioned earlier, this transformation is only applied once we've
already committed to evaluating the left and right sides.  So in the
example, above CVS mainline would generate.

	t1 = (a != 0);
	t2 = (b != 0);
	t3 = (c != 0);
	t4 = (d != 0);
	t5 = (e != 0);
	t6 = (f != 0);
	return t1 | t2 | t3 | t4 | t5 | t6;

With this patch, we simply factor out much of the code;

	t1 = a | b | c | d | e | f;
	return t1 != 0;

I agree with your point that chaining together operations that are
individually inexpensive may lead to an expression that is ultimately
more costly.  However, this is a flaw in the current GCC optimizer,
if anything this patch goes a long way to improving the situation.

> I am not quite sure whether we want to have this transformation at both
> levels and whether RTL or fold_const implementation is superrior. Both
> apepars to have their own advnatages and disadvantages.

It'll be easier to study the interactions of these two optimizations
once you submit your patch to this list.  However, remember again the
transformation in my patch is only applied after GCC has already decided
to remove all branches from the code.  As shown in your example above,
all I'm doing is subexpression reordering of straight line code, so I
doubt that this would have any interaction with the if-conversion passes.

Yes, there are always mysterious interactions between passes.  I've
been working a new GCSE based optimization that performs much better
on some well known benchmarks if "-fno-if-conversion" is specified.
The problem is that CFG-level optimizations don't apply once jumps
have been turned into straight line code, and GCC's current RTL
optimizations and x86 peepholes can't reproduce the jump-level
transformation.  C'est la vie.

Roger
--