On Sun, Nov 6, 2011 at 11:12 PM, Kai Tietz <kti...@redhat.com> wrote: > Hello, > > By this patch branch-cost optimization is moved from tree AST to cfgexpand > from gimple to RTL. By this we are able to do better optimization on > conditionals simliar for all targets and do the final transition for > branch-cost that late it shows best effect. > > This patch is splitted up into two pieces. First adds feature of BC > optimization to cfgexpand and scratches out BC-optimization code from > fold-const. > > The second patch adds to tree-ssa-ifcombine pass the feature to merge simple > if-and/or-if patterns into associative form. > > Two tests are failing due this patch in C's testsuite. This are > unit-pred-6_b and uniit-pred-6_c testcases. Those failures are caused by > jump-threading optimization in vrp, as vrp-pass. Those failures could be > fixed by the second patch, if we would move the ifcombine pass before the > first vrp pass.
The idea of doing target cost specific conversion of straight-line conditional code to branchy code and vice versa is a good one. Though technically the spot you chose isn't very suitable - we already performed SSA name coalescing so you do not have the freedom that you seem to exercise with using SSA name definition statements. Rather than hooking the logic into the place where we expand conditions this should be a "lowering" pass right before expansion (that would, hopefully at some point also do switch statement expansion/lowering according to target costs). Initially such patch should try to exactly copy what we do during expansion right now. The cond_chain stuff should be as we have discussed quite some time ago on IRC - modeled after tree-affine.c - a "vector" of predicates of the form [~] A op B, combined using logical AND or OR (thus, able to represent a disjunctive or conjunctive normal form). All suitably abstracted so if-conversion, the loop optimizer and loop number of iteration analysis can use this code (they all collect a controlling predicate (chain) and try to simplify against it). A patch adding a pre-expand pass should not at the same time change what we feed it - what we have before such pass in the IL should be driven by choice what canonical form is more optimal for optimization passes (and unfortunately we have conflicting requirements here - think of profile-feedback and the fact that we do not have SSA names for each predicate we compute). I note that there are still more patches from you pending related to predicate optimizations - but I lack an idea where you are heading to, from a global point of view. Take the time that stage3 and pre-stage1 offers to lay ground for a more structured approach to this area. You may, for example, want to pick up my (suspended) work on separating predicate computation from predicate use (or at least think about whether that's a good idea for the purpose of predicate optimizations). Thanks, Richard. > ChangeLog > > 2011-11-06 Kai Tietz <kti...@redhat.com> > > * cfgexpand.c (is_bool_op_p): New helper. > (normalize_truth_condition): Likewise. > (cond_assoc_t): New structure type. > (collect_cond_chain): New helper. > (build_cond_expr): Likewise. > (is_bitwise_binary_simple_combine): Likewise. > (preeval_cond_integral): Likewise. > (combine_conds): Likewise. > (branchcost_optimization_on_conditions): Likewise. > (expand_gimple_cond): Use branchcost_optimization_on_condition > function. > * dojump.c (do_jump): Prevent converting bitwise-and/or > to real iffs for branch-cost bigger then zero. > * fold_const.c (simple_operand_p_2): Improve evaluation > of side-effects and trapping for associative truth-bitwise > binary operations. > (fold_range_test): Remove branch-cost specific code. > (fold_truth_andor_1): Likewise. > (fold_truth_andor): Likewise. > > ChangeLog testsuite > > 2011-11-06 Kai Tietz <kti...@redhat.com> > > * gcc.dg/pr46909.c: Adjust test. > * gcc.dg/tree-ssa/vrp33.c: Likewise. > * gcc.target/i386/branch-cost1.c: Likewise. > * gcc.target/i386/branch-cost2.c: Likewise. > * gcc.target/i386/branch-cost3.c: Likewise. > * gcc.target/i386/branch-cost4.c: Likewise. > > Patch was bootstrapped and regression tested for x86_64-unknown-linux-gnu. > Ok for apply? >
