On Tue, Jul 13, 2021 at 12:50 PM Erick Ochoa <eoc...@gcc.gnu.org> wrote: > > > There are entities, like SSA names and STRING_CSTs which are specially > > encoded and if you stream those in your LGEN data you have to set up > > appropriate encoders. In general streaming arbitrary trees isn't the > > best thing to do, usually you're interested in specific pieces only. That's > > especially true for things "local" to a function (like SSA names), I think > > existing IPA passes only stream encoded references to global entities > > (or parameters) and all "local" info is some pass specific data streamed > > as raw data, not trees. > > Thanks! > > > > > Why do you want to stream SSA trees for example? > > > > I am working on a prototype for a points-to analysis where the > implementation is an IPA_PASS as opposed to a SIMPLE_IPA_PASS. It is > still somewhat early in the prototype implementation stages but I > would like to have SSA trees at WPA time as a way to map constraints > variables back to Gimple. The idea is to generate most constraints at > LGEN time (some will have to be updated) and solve them at WPA time. > > Do you have any other suggestions on how to map constraint variables > (similar to the index in the varinfo_t array) back to Gimple (but now > as an IPA_PASS)? We have had similar discussions before, but now I am > looking at things more concretely, from the point of view of: how > exactly does one map the analysis back to Gimple while staying within > what is possible in the LTO framework?
I guess the way to encode SSA trees would be to use sth like a <function-encoder>, SSA-version tuple much like PTA internally uses the varinfo array index as identifier for the variables in the constraints. For local decls (as opposed to SSA names) it's a bit more difficult - you'd have to devise your own encoding here. What you can rely on I think is that for local variables UID relations are preserved, so you could sort cfun->local_decls and use the position in this array as encoding (in fact I see local_decls is streamed literally, so you don't even need to sort that for the start - but we could likely do that without harm to make searching for a UID O(log n)). > I do have a pass-specific data structure, but it contains references > to trees. It is similar to varinfo_t, which has a decl. I also have > another tree for expressions (the concrete use case right now is > having a global variable being assigned to a string literal), and a > field for ssa variables, which was intended to store a reference to > the corresponding tree. Again, as a way to map back the constraint > variable to Gimple. > > > There can be no > > references to those from other IPA entities? > > I don't follow this question. I think this may be a statement and not > a question. Please clarify this for me, but perhaps the following > might answer: Since I am working on an interprocedural analysis, SSA > variables may point to abstract memory locations allocated in > different functions. So I need to have a link between SSA variables > and whatever memory locations they might point to. So as said above - you need to devise your own "encoder" then and at WPA time hopefully not need to look at the actual trees but can treat them as opaque entities, only mapping back the result at LTRANS time (and only for the interesting functions / globals). Richard.
