This is the mail archive of the
mailing list for the GCC project.
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
-----BEGIN PGP SIGNED MESSAGE-----
On 10/06/11 09:37, Jakub Jelinek wrote:
> 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).
I haven't followed this thread as closely as perhaps I should; what
I'm seeing discussed now looks a lot like condition merging and I'm
pretty sure there's some research in this area that might guide us.
multi-variable condition merging is the term the authors used.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----