This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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.