On Thu, Oct 06, 2011 at 05:28:36PM +0200, Kai Tietz wrote: > None. I had this implemented first. But Richard was concerned about > making non-IF conditions too long. I understand that point that it > might not that good to always modify unconditionally to AND/OR chain. > For example > > if (a1 && a2 && a3 && .... && a100) return 1; > > would be packed by this patch into 50 branches. If we would modify > all of them into AND, then we would calculate for all 100 values the > result, even if the first a1 is zero. This doesn't improve speed > pretty well. > > But you are right, that from the point of reassociation optimization > it could be in some cases more profitable to have packed all elements > into on AND-chain.
Yeah. Perhaps we should break them up after reassoc2, or on the other side teach reassoc (or some other pass) to be able to do the optimizations on a series of GIMPLE_COND with no side-effects in between. See e.g. PR46309, return a == 3 || a == 1 || a == 2 || a == 4; isn't optimized into (a - 1U) < 4U, although it could, if branch cost cause it to be broken up into several GIMPLE_COND stmts. Or if user writes: if (a == 3) return 1; if (a == 1) return 1; if (a == 2) return 1; if (a == 4) return 1; return 0; (more probably using enums). Jakub