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 Fri, 19 Oct 2007, Ian Lance Taylor wrote:

> Richard Guenther <rguenther@suse.de> writes:
> 
> > 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.
> 
> The connection we need is supposed to be built by
> compute_tbaa_pruning--specifically, it should mark the reference with
> no_tbaa_pruning.  Why isn't that working for you?

Because I didn't know of it.  But it also looks like it is local
to tree-ssa-structalias.c and not available at operand scanning time
(where we call access_can_touch_variable).  But maybe Danny didn't look
closely enough at my patch and access_can_touch_variable is the compeltely
wrong place to do TBAA pruning.

> > CHANGE_DYNAMIC_TYPE_EXPR is bad bad bad.  (But I guess I knew that
> > from the beginning... ;))
> 
> I think it's the C++ type aliasing rules which are bad bad bad.  If
> you can give us something which doesn't deoptimize your test case and
> also doesn't deoptimize other code, I'd be happy to hear it.  As you
> know I proposed several solutions for new aliasing, but you didn't
> like them because they deoptimized your specific unusual test case.
> Most code is not written like tramp3d.

The proposal I still like the most is to make the middle-end memory
model match that of C++ (or sort of).  Which was the proposal to
allow no sinking of loads and no hoisting of stores.  Which means
that writes alias everything (from TBAA perspective, PTA can override
this of course) and reads have to follow the usual C TBAA rules.
Of course the difficulty was to represent this asymmetry in the IL.

Richard.


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