Re: [PATCH] Improve VEC_BASE

[Richard Guenther <richard.guenther@gmail.com>]

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