This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: missed PTA optimization?


On Tue, Feb 11, 2020 at 10:27 PM Uecker, Martin
<Martin.Uecker@med.uni-goettingen.de> 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" <Martin.Uecker@med.uni-goettingen.de>
> > 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
> >
> >


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]