This is the mail archive of the
mailing list for the GCC project.
Re: Aliasing patch for tree-optimization/28778
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: gcc-patches at gcc dot gnu dot org
- Date: Sat, 26 Aug 2006 03:01:23 -0400
- Subject: Re: Aliasing patch for tree-optimization/28778
- References: <20060826033615.GA22342@nevyn.them.org>
Daniel Jacobowitz wrote:
> I attached a patch to Bugzilla that fixes this bug at the revision it first
> appeared. The current code has changed a bit, but the basic problem seems
> to be the same.
> # blistD.1872_1 = PHI <blistD.1872_3(3), blistD.1872_6(4)>;
> blist.0D.1874_7 = (const GLintD.1866 *) blistD.1872_1;
> # SMT.5D.1883_9 = V_MAY_DEF <SMT.5D.1883_8>;
> Variable: blistD.1872, UID 1872, const intD.0 *
> Variable: blist.0D.1874, UID 1874, const GLintD.1866 *, symbol memory tag:
> Variable: SMT.5D.1883, UID 1883, const GLintD.1866, is addressable, is
> global, call clobbered (, passed to call, is global var )
> structalias knows that blistD.1872_1 could point to list. But, it never
> reports that information, because it also knows that it could point to
> &ANYTHING. As a result nothing ever marks list as escaping, and it never
> gets marked as call clobbered.
This won't help you, in fact, as an optimization, the alias analysis
stops propagating edges to variables already marked as pointing to anything.
> I fixed this before by allowing variables to have both pt_anything and
> pt_vars in one more case. But nowadays set_pt_anything clears pt_vars, so I
> have the impression that either:
> - this isn't working the way it's supposed to, and list should be marked
> call clobbered through some other mechanism.
In particular, blist should be on the may-alias list of SMT.5, but
doesn't end up there.
> - or confusion about what pt_anything is supposed to mean has spread
> further through the code.
Nope, pt anything is separate than call clobbering.
pt_anything causes the SMT to be used, instead of the NMT. Thus, when
pt_anything is set, the SMT (in this case, SMT.5) should be listing the
variable as an alias, wihch it isn't.
pt_anything is about what variables can point to, not whether they are
clobbered by calls or not. It can help as a method to answer the
question of what variables are clobbered sometimes, but the question is
independent of asking what a variable points to.
> This patch, which I've tested on x86_64-pc-linux-gnu, fixes the test case.
> But I'm not entirely sure it's the right way to do it.
Sadly, it isn't :(
> If it is, should
> set_pt_anything not clobber pt_vars? If it's not, should aliasing be
> solving escaping as a dataflow problem to get the full set, so that we know
> what "clobbers anything" really clobbers?
We solve escaping as a transitive closure problem, which will give you
the conservatively correct set of escaping variables.
he real problem here is that for some reason we don't believe SMT.5
may-aliases blist.0, so the escaping code never marks blist.0 as being
Note that if you look at the aliasing dump, it says
find: Total number of aliased vops: 0
This is wrong, and likely triggers some if aliased_vops != 0 check
somewhere causing the underlying issue of not putting things into
SMT.5's may-alias list.
> Comments appreciated.
Part of the reason the code was rewritten was to separate the idea of
points-to and call clobbering and compute both properly :).
My *guess* is that if you convince it you have aliased vops, it will DTRT.
If not, you also have to get it to properly put blist.0 on SMT.5's