On Tue, Feb 11, 2020 at 10:27 PM Uecker, Martin
<[email protected]> wrote:
>
> Am Dienstag, den 11.02.2020, 21:43 +0100 schrieb Richard Biener:
> > On February 11, 2020 9:32:14 PM GMT+01:00, "Uecker, Martin"
> > <[email protected]>
> > wrote:
> > >
> > > In the following example, it seems
> > > that 'bar' could be optimized to
> > > return '1' and every else could be
> > > optimized away. Or am I missing
> > > something?
> >
> > p might be still NULL when bar is called.
> >
> > > Do I need to add
> > > some specific compiler flags?
> >
> > -fipa-pta
>
> This does not appear to change anything. Also
> if I initialize p to the address of 'a', this
> changes nothing.
>
> For the second function, I get:
>
> p = { ESCAPED NONLOCAL }
You have to look at the 0.86i.pta2 dump, there I see
p = { a } same as p.0_1
p.0_1 = { a }
if you then for example look at 100t.alias with -alias dumped you see this
local PTA pass is skipped:
Not re-computing points-to information because IPA points-to
information is available.
and we have
p.0_1, points-to NULL, points-to vars: { D.1929 } (nonlocal)
bar ()
{
int * p.0_1;
int _3;
<bb 2> [local count: 1073741824]:
# PT = null { D.1929 } (nonlocal)
p.0_1 = p;
_3 = *p.0_1;
return _3;
correctly saying that p.0_1 points to NULL or D.1929 (that's a). But
as I said nothing makes use
of this but a conservative correct "optimization" would be to transform this to
if (p.0_1)
_3 = a;
else
_3 = *p.0_1;
and eventually elide the conditional with some extra compile-flag
since it changes observable
behavior with POSIX in mind.
A slight complication is that the points-to sets contain DECL_UIDs but
there's no back-mapping
of UID to decl. The IPA points-to pass could do the transform since
it still knows the actual decl
though. Still I guess that the transform isn't a win in general so
handling it in value-numbering
would be better (but then the UID to decl issue arises).
> > But we simply do not implement turning pointer dereference into direct
> > accesses when points to
> > says it would be possible. And yes, the NULL case can probably be ignored
> > (though we generally
> > support catching NULL dereferences with signal handlers), or at least
> > speculated away with a well
> > predicted branch.
> >
> > Any situation where doing the above is profitable?
>
> No, just trying to understand what is happening.
> (clang does this optimization).
>
> Best,
> Martin
>
> > >
> > >
> > > static int a = 1;
> > > static int *p;
> > >
> > > extern
> > > void foo(void)
> > > {
> > > p = &a;
> > > }
> > >
> > > extern
> > > int bar(void)
> > > {
> > > return *p;
> > > }
> > >
> > >
> > > thank you,
> > > Martin
> >
> >
