On Fri, Sep 4, 2020 at 10:13 AM Erick Ochoa
<erick.oc...@theobroma-systems.com> wrote:
>
>
>
> On 03/09/2020 12:19, Richard Biener wrote:
> > On Thu, Sep 3, 2020 at 10:58 AM Jakub Jelinek via Gcc <gcc@gcc.gnu.org>
> > wrote:
> >>
> >> On Thu, Sep 03, 2020 at 10:22:52AM +0200, Erick Ochoa wrote:
> >>> So, I am just wondering is there an interface where I could do something
> >>> like:
> >>>
> >>> ```
> >>> // vars is the field in pt_solution of type bitmap
> >>> EXECUTE_IF_SET_IN_BITMAP (vars, 0, uid, bi)
> >>> {
> >>> // uid is set
> >>> tree pointed_to = get_tree_with_uid(uid);
> >>> }
> >>> ```
> >>
> >> There is not.
> >
> > And there cannot be since the solution includes UIDs of
> > decls that are "fake" and thus never really existed.
>
> Hi Richard and Jakub,
>
> thanks, I was looking for why get_tree_with_uid might be a somewhat bad
> idea.
>
> I am thinking about representing an alias set similarly to the
> pt_solution. Instead of having bits set in position of points-to
> variables UIDs, I was thinking about having bits set in position of
> may-alias variables' UIDs. I think an interface similar to the one I
> described can provide a good mechanism of jumping to different aliases,
> but I do agree that HEAP variables and shadow_variables (and perhaps
> other fake variables) might not be a good idea to keep in the interface
> to avoid jumping to trees which do not represent something in gimple.
>
> Richard, you mentioned in another e-mail that I might want to provide
> the alias-sets from IPA-PTA to another pass in a similar way to
> ipa_escape_pt. I think using a structure similar to pt_solution for
> may-alias solution is a good idea. Again, the bitmap to aliasing
> variables in UIDs. However, I think for this solution to be general I
> need several of these structs not just one. Ideally one per candidate
> alias-set, at most one per variable.
Sure, you need one per alias-set. Indeed you might want to work
with bitmaps of varinfo IDs first when computing alias-sets
since ...
> >
> > I think you need to first get a set of candidates you want to
> > transform (to limit the work done below), then use the
> > internal points-to solutions and compute alias sets for this
> > set plus the points-to solution this alias-set aliases. >
> > You can then keep the candidate -> alias-set ID -> points-to
> > relation (thus candidates should not be "all variables" for
> > efficiency reasons).
>
> I think I can use a relatively simple heuristic: start by looking at
> malloc statements and obtain the alias-sets for variables which hold
> malloc's return values. This should address most efficiency concerns.
>
> So, I'm thinking about the following:
>
> * obtain variables which hold the result of malloc. These are the
> initial candidates.
... those would be the is_heapvar ones. Since you can probably
only handle the case where all pointers either only point to a
single allocation sites result and nothing else or not to it that case
looks special and thus easy anyway.
> * for initial candidates compute alias-sets as bitmaps where only "real"
> decl UIDs are set. Compute this just before the end of IPA-PTA.
> * for each alias_set:
> for each alias:
> map[alias->decl] = alias_set
> * Use this map and the alias-sets bitmaps in pass just after IPA-PTA.
> * Potentially use something similar to get_tree_with_uid but that is
> only valid for trees which are keys in the map.
Hmm, isn't this more than you need? Given a set of candidates C
you try to form alias-sets so that all members of an alias set A
are members of C, they are layout-compatible and not member
of another alias-set. Plus no member escapes and all pointers
you can track may only point to a subset of a single alias-set.
>From the above C is what constrains the size of your sets and
the mapping.
> Does this sound reasonable?
>
> >
> > Richard.
> >
> >> Jakub
> >>
