[Bug tree-optimization/39074] [4.2/4.3/4.4 Regression] PTA constraint processing for *x = y is wrong

[rguenther at suse dot de]

------- Comment #14 from rguenther at suse dot de  2009-02-04 16:26 -------
Subject: Re:  [4.2/4.3/4.4 Regression] PTA
 constraint processing for *x = y is wrong

On Wed, 4 Feb 2009, dberlin at dberlin dot org wrote:

> ------- Comment #13 from dberlin at gcc dot gnu dot org  2009-02-04 16:09 -------
> Subject: Re:  PTA constraint processing for *x = 
>         y is wrong
> 
> I don't remember offhand.  At one point during 4.2 we used to compute
> the anything set exactly, and it led to massive issues. Of course,
> most of those were because the anything set had hundreds or thousands
> of SFT's :).
> 
> I'm happy to go with your idea for fixing since fixing shortcutting
> won't fix it, except for two things:
> 1. ANYTHING is really limited to all addressable variables (IE address
> taken and escaping), instead of all variables.  It was never meant to
> represent "completely unknown" (IE user has set pointer to  (char *)
> 0xdeadbeef).

Yes, is there a bitmap / array in the PTA graph that I can iterate
over instead of all vars?

> ISTM the set you union in should be based on CALLUSED and ESCAPED or
> something thereof, or at least should be computable with constraints
> during solving, and unioned in when it changes.

Ah, you mean whenever I see *ANYTHING = x union x into a new
STORE_TO_ANYTHING solution and have an explicit
*ANYTHING = STORE_TO_ANYTHING constraint (which I of course need
to handle properly in do_ds_constraint)?  That may be indeed faster.

> The way off the top of my head to do this is to simply stop using
> &ANYTHING, and use ANYTHING directly, and then have ANYTHING =
> CALLUSED and ANYTHING = ESCAPED.

I don't think CALLUSED or ESCAPED are related here.  You can store
non-addressables into *ANYTHING.

> Assuming you hate that idea for some reason
> 2. It's probably a lot faster to make a bitmap of these and update it,
> then union in the bitmap, than to iterate over all varinfos all the
> time.
> 
> ISTM you are trying to avoid doing #1 by adding all variables, even
> though this is going to give you worse than necessary results.
> 
> Intel actually iterates points-to solving in order to compute the set
> of nonlocal locations without explicitly adding the set everywhere.
> 
> See the description of nloc in section 4.1 of  "On the Importance of
> Points=To Analysis and Other
> Memory Disambiguation Methods For C Programs"

I'll have a look there.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074