This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
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