Re: tree decl stored during LGEN does not map to a symtab_node during WPA

[Richard Biener <richard.guenther@gmail.com>]

On Wed, Jul 21, 2021 at 6:55 PM Erick Ochoa <eochoa@gcc.gnu.org> wrote:
>
> Hello Richard, I need a little bit more help. In our previous messages
> you mentioned "<function-encoder>"
>
> > >
> > > > 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.
> > > >
>
> There was a little confusion on my part about what "encoder" meant
>
> >
> > > You mention that I need to devise my own "encoder", but I am not sure
> > > if we are conflating two notions:
> > >
> > > 1. encoding tree variables to constraint variables (i.e., a mapping of
> > > some tuple (cgraph_node x symtab_node x ssa-version) to an integer
> > > that represents the constraint variable)
> > > 2. encoding as an implementation of a data structure used during LTO
> > > to stream in and stream out trees/symbols to and from partitions.
> > > (e.g., lto_symtab_encoder_t).
> >
>
> And you proceed with the following answer
>
> > I meant 1) and streaming using the LTO cgraph encoder for the cgraph
> > part and simply using the SSA version for the second part.
> >
>
> From this exchange I understood that I should develop my own mapping
> for ssa variables and local declarations. However, when dealing with
> encoding a node which is available in the symbol table, I could use
> the function lto_symtab_encoder_encode to map symbols to an integer
> which would later make the symbol available at WPA time. Implicitly,
> for me, this meant that this integer is the same for every distinct
> symbol in different LGEN partitions. For example, if we encode symbol
> X from partitions Y and we get the number N, then encoding symbol X in
> partition Z should also yield N.
>
> I believe this is not the case, during WPA time I am printing:
> 1. pid of lgen process that generated the encoding
> 2. index returned by lto_symtab_encoder_encode
> 3. varpool_node->name ()
> 4. the pointer address being pointed by varpool node
>
> I think we had a previous discussion where it was mentioned that the
> only way to distinguish between these cases is to look at varpool_node
> cgraph_node:
>
> (From a different email edited for brevity)
>
> On Wed, 30 Jun 2021 at 19:38, Richard Biener <richard.guenther@gmail.com> wrote:
> >
> > On June 30, 2021 6:28:29 PM GMT+02:00, Erick Ochoa <eochoa@gcc.gnu.org> wrote:
> > >So how would I be able to say that two different declarations are the
> > >same variable?
> >
> > By looking at the associated varpool node.
> >
> > Richard.
> >
>
> If this is the case, I can indeed get the varpool node's at WPA time
> (as shown above), but comparing their pointer addresses will be
> distinct. How can one find out that two varpool nodes/cgraph nodes are
> the same at WPA time? Is just looking at the assembler name enough? I
> of course want this to be safe.

If they are the same they are merged by the symtab merging process done
at WPA time.

> Another question, how is this currently handled in other IPA passes?
> Alternatively, do you have suggestions for encoding functions and
> global variables in a similar way to how you suggested encoding ssa
> variables and local declarations?

I don't think any other pass has to encode SSA vars because those are
strictly function local.  They only handle IP invariants aka addresses of
globals or so.

Richard.