This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A case that PRE optimization hurts performance
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/27/11 01:30, Richard Guenther wrote:
>
>> It knows something about prephitmp.6_1 and thus could simplify
>> D.2734_9 = prephitmp_6.1 & D.2732_7; to D.2734_9 = D.2732_7; But
>> admittedly I have no idea if DOM tries to simplify things other
>> than comparisons within the jump threading machinery ... (the
>> above block basically ends in if (D.2729_6 != 0 &&
>> prephitmp_6.1), so I'd guess it's worth to simplify the (complex)
>> conditional expression).
Jump threading will enter simplified expressions into the hash tables
for every statement in the block in an effort to utilize any
information available to determine the result of the comparison.
However, those simplifications aren't ever reflected back into the IL.
The thing to remember is jump threading is tasked detecting cases
where the control statement has a predetermined destination utilizing
path sensitive information. Expanding it to do general path
sensitive optimizations is possible, but at even greater cost.
jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOgeQGAAoJEBRtltQi2kC7xX8H/1odgAgNVKdbWk4FtsNPx9xl
+xHtQdB2zycD0o0TMdQ+PcllXHaIK+ScIZEcxys1lN9HoEEyhyHPmQi7FZbD807y
oTswglsX7hnTM3fMCN62BTFwk6P0QNrbeZ4bsVxF5DkBmMLXbArQ7UEYD9mSHnDv
ixi06cUc/x5CXCAbcrAdUQI/9uF9d83myLs3rS3T0g2nPm+chGRN94Bm6ZbrB0hA
PjyKiZ4j3z6Yc5bs2GF19Rh7vfjD/9NhKF9t9YwuBky4luLv4RPFsT1JQM3+1yuT
tW5xk0et3eUnGFgiLUrF1mkHO/TkSv5iTsDI2tbbCkLCdH3w8Runj21/5qMWXxY=
=X10i
-----END PGP SIGNATURE-----