------- 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
