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

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

On Thu, Jul 22, 2021 at 2:04 PM Erick Ochoa <eochoa@gcc.gnu.org> wrote:
>
> > > 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.
>
> I trust you, but how would I verify it myself? For example, I
> mentioned that I printed:
>
> > 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

Well, yes, during LGEN no WPA has run.  Do you mean LTRANS after WPA?
Sure, the encoder numbers do not have to match up between different
LTRANS units but then they don't speak to each other so that shouldn't
matter, no?

> and I got the same "name" but different indices, and different varpool
> node's addresses for each of the lgen partitions. And of course
> there's only one global variable with that name. In other words, what
> exactly does it mean that they are "merged" and in which cases would
> they not get merged?
>
> What I'm seeing is for example:
>
> fopen $PID1 8 $ADDR1
> fopen $PID2 7 $ADDR2
>
> where $PID1 != $PID2 (expected since it was seen in two LGEN
> partitions). They were encoded as "8" and "7" in each of their LGEN
> partitions. And when reading them and printing the address of
> cgraph_node $ADDR1 != $ADDR2.
>
> So, previously when I thought that merged implied that $ADDR1 ==
> $ADDR2 this print shows that not to be the case. Also when I thought
> that merging implied they would have the same number, the different
> encoding showed that not to be the case. What I essentially want is
> the following:
>
> fopen $PID1 $ID
> fopen $PID2 $ID
>
> Where $ID can either be derived at WPA time or is encoded during LGEN.
>
> I'm wondering if I should "merge" these two constraint variables by
> checking their asm_name? I was just about to run an experiment to see
> different cases for this (i.e., same named static function and print
> their assembler name, etc.). This would be an example of $ID being
> derived at WPA time by doing an O(n^2) comparison in the number of
> functions, partitioning them into equivalent functions and then
> assigning each of the distinct partitions an incremental ID.

I _think_ that it should work if you stream at LGEN constraint variables
as their varpool node (using the varpool encoder), get the nodes merged
at WPA time, and thus your constraints from different LGEN runs "merged"
properly, then stream them the same way to the LTRANS units?

>
> >
> > > 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.
> >
>
> For SSA vars I followed your suggestion of having a function encoding
> and then using the SSA_VERSION number. Essentially <function encoding>
> x ssa version. However, since both varpool and cgraph_node are encoded
> in the same way (for which I am having problems), then the issue is
> with the function encoding.

And the same solution should exist.  For "merged" function definitions
(like multiple same inline definitions) you'd simply drop all but one set of
constraints.

Richard.