From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id EA06A3857C4C; Thu, 22 Jul 2021 11:40:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EA06A3857C4C Received: by mail-ej1-x636.google.com with SMTP id ga14so7921827ejc.6; Thu, 22 Jul 2021 04:40:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uvmxUXPd2ECqfu42Y5qIGGzdaO8t3ipRayaL9crjdmc=; b=KNWYbdBKcdaVI3lwi8ikcw5TpELK6ua7VZ/WBqxdLQGhh1XTkWDuwbMN9mGFyc2NfJ Z87UldJfkjHg8+uFWC/hoJXdcvxC1bSqPopHAve3oxeygn4RcUOSzbGb+2LOk5qAxMx6 u+MK6wgdkH/EwAjrdKSXK/b8Q8N7xa14JA+dqeHpGlf6f5TyHtbLCvRUuL6RyNRBdfde 5Wt8zjg9YiGNOQUZtbRPvRWSQU59BV1kHVY72D8IhtGYTgivLZL89TULaTLVIbgWDOBF BxDVnL70RBLivVcOR0JWIkka+ZUqsgk+hcgvhFVa+K8A+A6OP/LQ2mLAnalWjuhl9h3E hjkA== X-Gm-Message-State: AOAM531WnTqD6qkUvwa4sv+SMQGU8USYi7184MbMsUZt3OPegSL0sJWK Mj+HE4XPtQcwpGJPThCRPEvLEIkDcNjzqur9E3978YB3 X-Google-Smtp-Source: ABdhPJzQLFf25T260eSWk7Qw8lfCen1emuBtBRq+Lwu7Uq9hI2PthJa6OGJ9mNgb191Rlre+kO+L0ZZvK6WHLWVFgwo= X-Received: by 2002:a17:906:c29a:: with SMTP id r26mr44139101ejz.235.1626954050754; Thu, 22 Jul 2021 04:40:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 22 Jul 2021 13:40:39 +0200 Message-ID: Subject: Re: tree decl stored during LGEN does not map to a symtab_node during WPA To: Erick Ochoa Cc: Jan Hubicka , GCC Development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 11:40:53 -0000 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 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 wrote: > > > > On June 30, 2021 6:28:29 PM GMT+02:00, Erick Ochoa 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.