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: Aliasing patch for tree-optimization/28778


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)>;
> <L2>:;
>   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:
> SMT.5D.1883
> 
> 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.
Yes.

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
call clobbered.

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
may-alias list.

HTH,
Dan


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