CFG merge part 21 - double test conversion pass

Jan Hubicka jh@suse.cz
Sun Jun 2 14:51:00 GMT 2002


> On Sat, Jun 01, 2002 at 08:24:51PM +0200, Jan Hubicka wrote:
> > 	* ifcvt.c (num_possible_double_test_blocks,
> > 	num_updated_double_test_blocks, num_removed_blocks_double_test): New
> > 	static variables.
> > 	(double_test_info): New structure.
> > 	(nonzero_test, double_test_ior_and, m1_test, find_double_test_block,
> > 	process_double_test_block, block_side_effects_p): New static functions.
> > 	(find_if_header): Call find_double_test_block.
> > 	(dead_or_predicatble): Properly update LABEL_NUSES.
> > 	(if_convert): Output statistics.
> 
> Have you looked to see how this handles three or more tests?
> Does it sort of chain them together creating weird setcc 
> patterns with the result of the first-merged test?

In most cases this works just fine.
In case of (a || b || c || d...)
it simply converts to
((a | b) || c || d
and continues until the block probability cummulates high then
it iterrupts the chain.
So results in ((a | b | c | d) || (e | f | g)).

Since all tests are currently converted to tests of zero-ness and
nonzeroness of integer value, the tests chain well and often simplify by
combine later.
> 
> How much work to convert the thing such that it collects
> multiple tests all at once?  That would certainly make ia64
> parallel compares easier to generate...

It should not be that dificult to do.  I may do it directly, or
incrementally.  Another interesitng case would be to convert
(a == 1 || a == 3 || a == 5)
into shifting and masking, that is profitable only for 3 and more tests.

Honza
> 
> 
> r~



More information about the Gcc-patches mailing list