CFG merge part 21 - double test conversion pass
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
> 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.
More information about the Gcc-patches