-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/07/11 15:53, Richard Guenther wrote: > On Mon, Nov 7, 2011 at 10:25 PM, Jakub Jelinek <ja...@redhat.com> > wrote: >> Hi! >> >> This patch attempts to optimize VEC_BASE if we know that offsetof >> of base is 0 (unless the compiler is doing something strange, it >> is true). It doesn't have a clear code size effect, some .text >> sections grew, supposedly because of more inlining, some .text >> sections shrunk. >> >> Bootstrapped/regtested on x86_64-linux and i686-linux. > > I wonder why the compiler doesn't optimize this ... certainly it > looks backward to, in > > <bb 2>: if (c_2(D) != 0B) goto <bb 3>; else goto <bb 4>; > > <bb 3>: D.2948_3 = &c_2(D)->fld; goto <bb 5>; > > <bb 4>: D.2948_4 = 0B; > > <bb 5>: # D.2948_1 = PHI <D.2948_3(3), 0B(4)> return D.2948_1; > > see that D.2948_4 is equal to D.2948_3 for c_2 == 0, so I'm not > sure which pass would be able to detect this (but the optimziation > opportunity would be on the PHI node, so maybe it should be done in > phiopt). Right, I see that now.
But D2948_3 doesn't flow through block #4, thus we can't use its value for the PHI arg associated with the edge 4->5. So even with the equivalency I think to optimize this we'd have to detect the construct as a whole and collapse it into &c_2->fld. Presumably that's what your patch in a later message does. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOuYRuAAoJEBRtltQi2kC7E2YH/1ayeLWX3GoOnq5u+JxpyWkx Fh/Dnar+Ad2jJJMrbx7vUUhAH54OEUDTWKYMQOn8ThUTnMmQtgb4uNqdyO78RfyM BIVzzpTjD3Ud1+xxlzg8YCjvBw/NekRp9l4HiZpwwRIfTQRpKhWZ+oWe3bBgs+4B LCVQWA9I5cGBhv09u7OOsYhicuAUa1Tj/XNF4NWE1GVsjilj+ESvZUj5Zd7dvxft QzGh0fNn+RB9LVu6kktvU5CCX/sVBjVDnTaOP14zYGAEMFrWYjanE0n9+b6cVf9W degmRowfMzOLvphsWEPFVZCTJPuDfkLlc5k6X3MkgpEFwQu6uo2S/k8vd98PAr8= =vcgh -----END PGP SIGNATURE-----
