This is the mail archive of the gcc-patches@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: [PATCH] Fix PR32921, prune virtual operands of memory accesses based on TBAA


On Thu, 18 Oct 2007, Daniel Berlin wrote:

> On 10/18/07, Richard Guenther <rguenther@suse.de> wrote:
> > On Thu, 18 Oct 2007, Richard Guenther wrote:
> >
> > >
> > > Now, I was totally suprised to see that while we prune virtual operands
> > > (in the case of PR32921 a bunch of SFTs) based on the offset of the access
> > > but not based on TBAA.  Duh.  Fixed with the following patch that will
> > > do so for all alias symbols (apart from MPTs, those would need more
> > > special treatment).  I also took the liberty to re-shuffle things a bit
> > > in access_can_touch_variable.
> > >
> > > Maybe I'm missing something obvious here, but a slightly less invasive
> > > patch (just pruning SFTs) bootstrapped & tested fine.
> > >
> > > This patch is currently bootstrapping and testing on
> > > x86_64-unknown-linux-gnu for all languages including Ada.
> > >
> > > Danny?  Am I just crazy this day?
> >
> > Of course things are never that easy.  As for now we only miscompiled
> > the fortran frontend I at least found a new alias stressing testcase ;)
> > (HEAP variables do not have a type meaningful for TBAA)
> >
> > I expect maybe similar fallout for NMTs, but I'm sure SMTs and SFTs
> > are correct in this respect.
> >
> > So the following is bootstrapping & testing now.
> This looks fine to me.
> 
> Yes, HEAP vars have no real type, and can't be pruned.
> NMT's should always be the correct type.

Ok, it get's more complicated.  First of all, we need to handle
the may_alias attribute.  That's easy enough, just add

      /* If the inner reference has alias set zero, we cannot use the
         type of the access for TBAA purposes.  This happens with
         the use of attribute may_alias.  */
      && (!base || get_alias_set (TREE_TYPE (base)) != 0)

The bad thing is that Fortran gives arrays of real8 alias set zero
for example.  For a reason I still need to investigate.  So this
no longer fixes PR32921.

But then the killer issue comes along.  The way we designed
CHANGE_DYNAMIC_TYPE_EXPR makes it impossible to do TBAA pruning on
memory accesses.  For g++.dg/init/new16.C we have

    int *l = (int *)p;
    *l = 0;
    f = new (p) long;
    *f = -1;

  l_7 = (int *) p_6(D);
  *l_7 ={v} 0;
  <<<change_dynamic_type (long int *) p_6(D))>>>
  D.2035_15 = p_6(D);
  f_10 = (long int *) D.2035_15;
  *f_10 ={v} -1;

but we do not have a connection of the CHANGE_DYNAMIC_TYPE_EXPR to
the memory reference site.  So we happily prune SMT.17 from f_10s
alias set.

  l_7 = (int *) p_6(D);
  # SMT.17_20 = VDEF <SMT.17_17>
  *l_7 = 0;
  D.2035_15 = p_6(D);
  f_10 = (long int *) D.2035_15;
  # SMT.16_21 = VDEF <SMT.16_16>
  *f_10 = -1;

Because out IL doesn't really tell the truth.  Which even makes me
uncomfortable to just enable TBAA pruning for SFTs and bare DECLs.
But I guess that should work.

CHANGE_DYNAMIC_TYPE_EXPR is bad bad bad.  (But I guess I knew that
from the beginning... ;))

Richard.


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