-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/08/11 02:45, Richard Guenther wrote: > On Tue, Nov 8, 2011 at 1:29 AM, Jeff Law <l...@redhat.com> wrote: >> -----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). >> ?!? When c2 == 0 the return value is supposed to be zero, that's >> one of the fundamental problems with the way we've defined >> VEC_BASE. >> >> In fact cases where we immediately dereference VEC_BASE are >> precisely what got me looking at the executable path >> optimization. >> >> Assuming this gets inlined and the result is used in a memory >> dereference, the new pass will do exactly what we want. Namely >> it'll determine that BB4 can never be executed at runtime and >> it's control dependent on the edge 2->4. It zaps the edge 2->4, >> cleaning up the conditional in the process. That makes BB4 >> unreachable and BB2, BB4 and BB5 mergable and everything >> collapses into one simple assignment. > > But there is no dereference in the code above - &c->base is an > address computation. But we can still optimize I know there's no dereference, I was indicating what would happen if the result was ultimately dereferenced by the caller of VEC_BASE. That's a common scenario.
> > if (c) return &c->base; return NULL; > > to > > return &c->base; Yea yea, silly me should have known that "base" would be at offset zero thus leading to the equivalency. Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOuYD9AAoJEBRtltQi2kC74yUH/2yiwrvNoy3v/nAO2ypdIYzn KrjySX1gBwc3ZUIyus4B+OiyQwTe/F4k6mkRJftGQtdG0eADQbq87LoBAfNTJKDy 1VY8UM6NqSE3eejtgBkOftoTsBZGAgUe0IEhOGp1lig7o4hI/Hcf7p1IYmT4+Lxz wl8DQgMc9F1JS6pyWzz5dpGVeEW90RPoN1tyTufAIiKTRogmw2qk44JZhieai7KN 46LuHZ1VwYrTZuBZGr0gdt3uigdFkpDFbKcAu2o8pcjCdcx8CD8XPuSej2nCYTPE fKc4fwjfgDTbUyLj8knbEEUwpTNkHidE9pehvvPxxPhQkmKUg5x+UJl5wjGL1Zc= =iiK4 -----END PGP SIGNATURE-----
