This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOjeYFAAoJEBRtltQi2kC7eFMIALjFM/GIg1DDryU59EoFQe5A
x7pvx3FSlcjLWeyIlzYJvWF4wGybRNNXp5qziIedO6qp0Z/06VvCU07A10VoWSig
/EFufo5l+Jef5s1d0mA6mBJ9A52HDL2ipOK8YDQbVzJWqHdaXLrrzUni3wGwcUVs
v3UIi5OevjRhJ55fRVxBcReJKF6YAzxFDxqOnVGAbf9R3BEJ2T9JW2CLhIcd/T1L
D9K+6YymHaN9eYh7B7gPKG88q+5JjcStHuMQODKSAegt3T4iP9CH/G5dV8u95Y+q
6mxo8gOGAwYR7N/U6fuXRaGJEzWSdrqRy2EBF5B7+Rt6lSWXdfzUEBusT24i67A=
=HIrU
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]