On Fri, Sep 4, 2020 at 4:36 PM Erick Ochoa
<erick.oc...@theobroma-systems.com> wrote:
>
>
>
> On 04/09/2020 15:19, Richard Biener wrote:
> > 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 ...
>
> Yes, that's what I've been doing :)
>
> >>>
> >>> 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.
>
> I did a git grep and is_heapvar is gone. But, I believe that I still
> collect these variables as quickly as possible. I iterate over the call
> graph and if I find malloc, then I just look at the callers and collect
> the lhs. This lhs corresponds to the "decl" in the varinfo_t struct.
>
> I then just iterate over the variables in varmap to find matching lhs
> with the decl and computing alias sets by looking at the intersection of
> pt_solution. This seems to work well. I still need to find out whether
> they escape, but it should be simple to do so from here.
>
> >
> >> * 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.
>
> Yes? I'm not really sure what you are trying to say here. Can you please
> elaborate more on "this" in the sentence "isn't this more than you need?".
>
> I think I need a way that given some tree (which I know is in
> candidates) I can refer to its alias set. Since the given set of
> candidates might have more than 1 opportunity for transformation (i.e.
> computing the alias-sets for all c in C yields two distinct alias sets
> A_0 = {c_0, c_1, ... c_x}, A_1 = {c_x+1, ... c_y} ) I need a way of
> referring to these distinct alias sets. Here, I was hoping to refer to
> alias sets by the members of the sets themselves.
>
> c_0 -> A_0
> c_1 -> A_0
> ...
> c_x+1 -> A_1
> c_x+2 -> A_1
>
> The get_tree_with_uid interface is more of a quick way to find out if
> they are layout compatible. Because if we have a bitmap...
>
> for a in A_0:
> for b in A_0:
> tree_a = get_tree_with_uid(a)
> tree_b = get_tree_with_uid(b)
> if (!layout_compatible(tree_a, tree_b)) return false;
Hmm, I thought you'd maybe do the following when you
need to merge two alias sets:
if (!layout_compatible (pick-one-from-A1, pick-one-from-A2))
mark result as alias-set of non-eligible vars
so you'd end up with alias-sets that only contain layout compatible
members or are marked as containing non-(no longer-)candidates only.
You can then continue by walking / remembering the "good" alias-sets
only.
Richard.
>
> >
> > From the above C is what constrains the size of your sets and
> > the mapping.
> >
> >> Does this sound reasonable?
> >>
> >>>
> >>> Richard.
> >>>
> >>>> Jakub
> >>>>
