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;
From the above C is what constrains the size of your sets and
the mapping.
Does this sound reasonable?
Richard.
Jakub
