This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix flow-insensitive alias computation
On Fri, 18 Apr 2008, Daniel Berlin wrote:
> On Fri, Apr 18, 2008 at 5:04 AM, Richard Guenther <rguenther@suse.de> wrote:
> > On Thu, 17 Apr 2008, Daniel Berlin wrote:
> >
> > > On Thu, Apr 17, 2008 at 11:48 AM, Richard Guenther <rguenther@suse.de> wrote:
> > > >
> >
> > > > Eventually
> > > >
> > > > if (may_aliases2 && !bitmap_empty_p (may_aliases2))
> > > > {
> > > > union_alias_set_into (tag1, may_aliases2);
> > > > }
> > >
> > > Errr, this was not added at some point to fix anything, AFAIK. The
> > > code there was simply transformed from a loop over the aliases into a
> > > bitmap or :)
> >
> > Heh, you are right. All of the above code was added effectively with
> > r87515.
> >
> > To clarify what I mean with the symmetry problem consider
> >
> > struct X {
> > int i;
> > double x;
> > } s;
> > int test3 (struct X *p1, int *p2, double *p3)
> > {
> > p1->i = 1;
> > *p2 = 2;
> > *p3 = 3;
> > return p1->i;
> > }
> >
> > where we at the moment do
> >
> > test3 (struct X * p1, int * p2, double * p3)
> > {
> > int D.1572;
> >
> > <bb 2>:
> > # SMT.30_9 = VDEF <SMT.30_6(D)>
> > # SMT.31_10 = VDEF <SMT.31_7(D)>
> > # SMT.32_11 = VDEF <SMT.32_8(D)>
> > p1_1(D)->i = 1;
> > # SMT.30_12 = VDEF <SMT.30_9>
> > # SMT.31_13 = VDEF <SMT.31_10>
> > *p2_2(D) = 2;
> > # SMT.30_14 = VDEF <SMT.30_12>
> > # SMT.32_15 = VDEF <SMT.32_11>
> > *p3_3(D) = 3.0e+0;
> > # VUSE <SMT.30_14, SMT.31_13, SMT.32_15>
> > D.1572_4 = p1_1(D)->i;
> > return D.1572_4;
> >
> > }
> >
> > which is ok for the accesses through the pointers *p2 and *p3 but
> > unnecessarily includes the SMT for double in the access of p1->i.
> >
> > This is caused by several places, one flow insensitive alias
> > computation being symmetric,
>
> There is little you can do about this, since our tbaa sets are
> designed to be symmetric.
Really? The alias_set_subset_of is not symmetric, which is what I am
refering to. Still we make SMT.1 alias SMT.2 if SMT.2 aliases SMT.1
(at least we use alias_set_subset_of vs. alias_sets_conflict_p
inconsistently in the tree alias code).
> > another find_what_p_points_to
> > calling merge_smts_into for pt_anything pointers and that
> > adding all subsets to the solution (which gets merged back
> > to the SMT aliases in flow sensitive alias compuation). It's
> > all a little bit of a twisted maze and the problem can be
> > at least worked around in access_can_touch_variable (as I
> > proposed once before).
>
> Yes, this is pretty ugly, sadly.
>
> It is all a workaround for the fact that we don't put aliasing in
> terms of variables in other procedures, etc.
I don't understand this, can you elaborate?
> Without addressable local vars, the only thing that stops us from
> getting wrong answers is adding SMT's to represent unknowns.
Well, yes. The TBAA symbols are supposed to be a safe fallback.
> > So I believe the following should be in principle correct modulo
> > latent bugs elsewhere...
>
> This looks fine to me, but be careful.
> As you've discovered, this part of the code is very very fragile.
It actually works. I am thinking to force PTA off and see if
anything breaks that way (that basically forces the operand scanner
to fall back to the pointers SMT all the time).
Richard.