[PATCH] Improve VEC_BASE

[PATCH] Improve VEC_BASE

[Jakub Jelinek]

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.

2011-11-07  Jakub Jelinek  <jakub@redhat.com>

	* vec.h (VEC_BASE): If base is at offset 0 in the structure,
	use &(P)->base even if P is NULL.

--- gcc/vec.h.jj	2011-09-08 11:21:10.000000000 +0200
+++ gcc/vec.h	2011-11-07 18:45:33.000000000 +0100
@@ -549,7 +549,12 @@ typedef struct VEC(T,A)							  \
 } VEC(T,A)
 
 /* Convert to base type.  */
+#if GCC_VERSION >= 4000
+#define VEC_BASE(P) \
+  ((offsetof (__typeof (*P), base) == 0 || (P)) ? &(P)->base : 0)
+#else
 #define VEC_BASE(P)  ((P) ? &(P)->base : 0)
+#endif
 
 /* Vector of integer-like object.  */
 #define DEF_VEC_I(T)							  \

	Jakub

Re: [PATCH] Improve VEC_BASE

[Richard Guenther]

On Mon, Nov 7, 2011 at 10:25 PM, Jakub Jelinek <jakub@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).

Would you open a bugreport for this please?

Ok.
Thanks,
Richard.

> 2011-11-07  Jakub Jelinek  <jakub@redhat.com>
>
>        * vec.h (VEC_BASE): If base is at offset 0 in the structure,
>        use &(P)->base even if P is NULL.
>
> --- gcc/vec.h.jj        2011-09-08 11:21:10.000000000 +0200
> +++ gcc/vec.h   2011-11-07 18:45:33.000000000 +0100
> @@ -549,7 +549,12 @@ typedef struct VEC(T,A)                                                      \
>  } VEC(T,A)
>
>  /* Convert to base type.  */
> +#if GCC_VERSION >= 4000
> +#define VEC_BASE(P) \
> +  ((offsetof (__typeof (*P), base) == 0 || (P)) ? &(P)->base : 0)
> +#else
>  #define VEC_BASE(P)  ((P) ? &(P)->base : 0)
> +#endif
>
>  /* Vector of integer-like object.  */
>  #define DEF_VEC_I(T)                                                     \
>
>        Jakub
>

Re: [PATCH] Improve VEC_BASE

[Jeff Law]

-----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 <jakub@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.

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

iQEcBAEBAgAGBQJOuHf+AAoJEBRtltQi2kC7QIEH/0/Agi9ClHIomtqYcCJzmJnk
Agrg2ojaJp6KwEq8a//PpOk8Ja4ZuUvTpE71PuDQgDaUWWapd04GuPQMxLE65oho
HZBW0CuIgN4IvrsQCnvzx6uMKRFtE4AZx+dmrWCtE0uKuXQFW2lcnPDWb0oEdT+D
dsekkWb3BcRMDwVxBlbEUpzxOqVRSWnUuCTtLFCuGRdUOHqyjVp0eOtt+DkAPcXH
CM3aVxZDGx9EfMISoZqCD3SkmAgAcYeTRiTsl7Mjkzo+XIivMxm6o9WgJrp1gW0E
sdBN3XQcwYgpg9en7O0HGqyDqYBjDG2u3i4kh6uE549/m+e7vPFdAbxpyg8zJZI=
=hRN5
-----END PGP SIGNATURE-----

Re: [PATCH] Improve VEC_BASE

[Richard Guenther]

On Tue, Nov 8, 2011 at 1:29 AM, Jeff Law <law@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 <jakub@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

if (c)
  return &c->base;
return NULL;

to

return &c->base;

if &c->base == NULL iff c == NULL.

So I think this is orthogonal to any undefinedness of dereferencing.

The above pattern occurs frequently so that the computed address
is either a valid dereferencable address or NULL.

Richard.

Re: [PATCH] Improve VEC_BASE

[Richard Guenther]

On Tue, Nov 8, 2011 at 10:45 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Nov 8, 2011 at 1:29 AM, Jeff Law <law@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 <jakub@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
>
> if (c)
>  return &c->base;
> return NULL;
>
> to
>
> return &c->base;
>
> if &c->base == NULL iff c == NULL.
>
> So I think this is orthogonal to any undefinedness of dereferencing.
>
> The above pattern occurs frequently so that the computed address
> is either a valid dereferencable address or NULL.

Thus, a similar testcase would be

int f(int i)
{
  if (i)
    return i;
  return 0;
}

phiopt optimizes that, but it fails to optimize

struct C { int i; };
int *g(struct C *p)
{
  if (p)
    return &p->i;
  return (int *)0;
}

but that's also because we do not optimize &p->i to just p.

Richard.

> Richard.
>

Re: [PATCH] Improve VEC_BASE

[Jeff Law]

-----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 <law@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
>>> <jakub@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-----

Re: [PATCH] Improve VEC_BASE

[Jeff Law]

-----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 <jakub@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-----

Re: [PATCH] Improve VEC_BASE

[Richard Guenther]

On Tue, Nov 8, 2011 at 8:35 PM, Jeff Law <law@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 <jakub@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.

Yes.  It collapses it into c_2.  As pointer type differences are no longer
important in the GIMPLE IL we can represent &c_2->fld simply as c_2
and thus with copy propagation we'd present phiopt with something
it already handles.  Unfortunately rewriting all &c_2->fld style expressions
simply as c_2 plays foul with _FORTIFY_SOURCE and object size
computation (where it makes a difference which field at offset zero
you access ...).  So instead of canonicalizing address computations
using ADDR_EXPR to POINTER_PLUS_EXPR in general for 4.7 the
only thing we can do is special case the above case in phiopt (which
is probably worthwhile - that pattern ought to be quite common).

Richard.

> 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-----
>

Re: [PATCH] Improve VEC_BASE

[Jeff Law]

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

On 11/07/11 14:25, Jakub Jelinek 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.
> 
> 2011-11-07  Jakub Jelinek  <jakub@redhat.com>
> 
> * vec.h (VEC_BASE): If base is at offset 0 in the structure, use
> &(P)->base even if P is NULL.
Presumably this becomes redundant with we went with Richi's patch?

jeff

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

iQEcBAEBAgAGBQJOvLmLAAoJEBRtltQi2kC7BNUIAJMJvrpgtSfIrPDZ/JHXM1on
Td5M5ebXO7lgdf5W5SJU5WiuRqHG2N+J/YJ9mJgUaCdLrbKJQXTdU/jbMaJqbwlR
g1LU7nMHM2Kf87zXdJCdcuB7BfMfmVcpNVopuab1GA6nRye9ru3+SXpXbDSiNmeM
1j8r1IEeL37sWPX2opUHgE9bQfaqDigonlPiqw+JxWQXGBpAvy2xS5CNd93RoN80
SLtHnxWoULpwJ16E9mpgTtR8kG8mFYaWAuWDKMpTX21hK/nTIkjGpFEOHddIjI8n
z/c3zUcjrJujQ773qReSEY0tLdtrckS7/Gy01tIc+yMus7VmVfdt4lpabeoXwX4=
=mJd5
-----END PGP SIGNATURE-----

Re: [PATCH] Improve VEC_BASE

[Jakub Jelinek]

On Thu, Nov 10, 2011 at 10:58:36PM -0700, Jeff Law wrote:
> > 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.
> > 
> > 2011-11-07  Jakub Jelinek  <jakub@redhat.com>
> > 
> > * vec.h (VEC_BASE): If base is at offset 0 in the structure, use
> > &(P)->base even if P is NULL.
> Presumably this becomes redundant with we went with Richi's patch?

I've actually committed it yesterday after discussion with Richi on IRC.
While his patch optimizes it, it doesn't do so for -O0 and isn't performed
during the early passes.  For -O0 the offsetof == 0 should be folded to 1
and the test should be eliminated and for -O1+ it may affect inlining
decisions.

	Jakub

Re: [PATCH] Improve VEC_BASE

[Jeff Law]

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

On 11/11/11 00:53, Jakub Jelinek wrote:

> 
> I've actually committed it yesterday after discussion with Richi on
> IRC.
No problem.

> While his patch optimizes it, it doesn't do so for -O0
Funny, I almost make this argument for accepting your patch, then
decided it wasn't that compelling.

Anyway, I'm fine with the patch, just wanted to make sure it was
resolved one way or another.

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

iQEcBAEBAgAGBQJOvWG/AAoJEBRtltQi2kC7reIH/3g/v/GgVp5xI10iV5ZKUj5u
h4PfJjoGUP/skivOW9ZEPcsX7NTwPRu+9vuBER+s4D9TBZJk9T5PmjNYF87xNsOP
vjBZJzSZEcmiTm/2ixkYTMfU9AwO3jImbvECtPjxqIarzm9LNvsn4P/TwlviqMcs
0FEEXOuHxPV/L8zdc0SewvoR8GnnMWRg2leBt5ypNF/D43ozCNaGJrUOB5Z0DGcN
52a9WjotLuEXfs4/P8uMoXyMfr1grWdocX+g3NXrAkssU0Dj6V9tbJw8JG/XG/Px
TgI8iHmGN9EX8W8qTtllbj3j5W7KESpCvfK346pY+dr8QpoO32BjPqrHvQ6U5ZE=
=tjF9
-----END PGP SIGNATURE-----