On Thu, Jul 22, 2021 at 4:33 PM Erick Ochoa wrote:
>
> >
> > But the addresses are at LGEN time?
>
> The following is what runs at WPA time
>
> unsigned long pid = streamer_read_uhwi (&ib);
> unsigned long id = streamer_read_uhwi (&ib);
> lto_symtab_encoder_t encoder = file_data->symtab_node_encod
>
> But the addresses are at LGEN time?
The following is what runs at WPA time
unsigned long pid = streamer_read_uhwi (&ib);
unsigned long id = streamer_read_uhwi (&ib);
lto_symtab_encoder_t encoder = file_data->symtab_node_encoder;
cgraph_node *cnode =
dyn_cast(lto_symtab_encoder_deref(encoder,
On Thu, Jul 22, 2021 at 2:33 PM Erick Ochoa wrote:
>
> > > > 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
> > > 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 numbe
On Thu, Jul 22, 2021 at 2:04 PM Erick Ochoa 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 t
>
> fopen $PID1 8 $ADDR1
> fopen $PID2 7 $ADDR2
>
Just to clarify a bit further. $PID is generated and stored during
LGEN. The encoding is obviously generated during LGEN.
These are read during WPA. And the encoding is decoded and dyn_casted
into a cgraph_node at WPA time.
All these are printed du
> > 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 co
On Wed, Jul 21, 2021 at 6:55 PM Erick Ochoa wrote:
>
> Hello Richard, I need a little bit more help. In our previous messages
> you mentioned ""
>
> > >
> > > > I guess the way to encode SSA trees would be to use sth like a
> > > > , SSA-version tuple much like PTA internally
> > > > uses the vari
Hello Richard, I need a little bit more help. In our previous messages
you mentioned ""
> >
> > > I guess the way to encode SSA trees would be to use sth like a
> > > , SSA-version tuple much like PTA internally
> > > uses the varinfo array index as identifier for the variables in the
> > > constr
On Wed, Jul 14, 2021 at 3:56 PM Erick Ochoa wrote:
>
> > I guess the way to encode SSA trees would be to use sth like a
> > , 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 name
> I guess the way to encode SSA trees would be to use sth like a
> , 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
On Tue, Jul 13, 2021 at 12:50 PM Erick Ochoa 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,
On Tue, 13 Jul 2021 at 11:41, Richard Biener 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.
I forgot to ask, is there an example of these appropriate encoders
being use
> 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
> es
On Tue, Jul 13, 2021 at 11:21 AM Erick Ochoa wrote:
>
> Hi,
>
> Just to clarify a similar question: I am using stream_write_tree and
> looking at the comments it says that it is assumed that the tree T is
> already in the encoder cache. Does this mean that I have to use
> lto_symtab_encoder_t for
Hi,
Just to clarify a similar question: I am using stream_write_tree and
looking at the comments it says that it is assumed that the tree T is
already in the encoder cache. Does this mean that I have to use
lto_symtab_encoder_t for all trees I want to store in summaries? I
thought the encoder only
> I'm not too familiar with it but I think you're supposed to stream encoded
> symtab references during LGEN/WPA,
Thanks Richard, this happened to be the solution. I am now using
lto_symtab_encoder_t to encode the declarations during LGEN and decode
them during WPA.
Are there any more limitations
On Fri, Jul 9, 2021 at 9:52 AM Erick Ochoa via Gcc wrote:
>
> Hi, I noticed this is also happening also for local variables. Again,
> storing tree declarations on a summary during LGEN and then at WPA
> time reading from those summaries. I can print the declaration, but
> when I try to look for it
Hi, I noticed this is also happening also for local variables. Again,
storing tree declarations on a summary during LGEN and then at WPA
time reading from those summaries. I can print the declaration, but
when I try to look for its node in the symtab I get NULL as the return
value.
Any help is app
Hi,
I am saving some tree declarations during LGEN that I will be later
analyzing at WPA time. I am able to read the decl from my summaries
and print it at WPA time. It corresponds to a global variable.
However, whenever I use symtab_node::get (decl) during WPA time I keep
getting NULL.
Does anyo
20 matches
Mail list logo
