From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by sourceware.org (Postfix) with ESMTPS id C2EEB383B82A for ; Wed, 21 Jul 2021 16:55:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C2EEB383B82A Received: by mail-lj1-f182.google.com with SMTP id d17so3803158ljq.12 for ; Wed, 21 Jul 2021 09:55:57 -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=MxQ3pbfbbhw8UmRiKCbHzU5U1cQLA8o6QcAaqrQSAdI=; b=dTqSx4LTWphuMt0/NlAvX/JwrjFZksU+OkrAmiAdt3GaRj1iy/9D9YoXr78d2ZizSV 8W8Bi7qXCsa3PlSHY+Xv2trD6coZlIkpvuTvhJyOJ9Q0WB2SqZmpfxm7AwJ50vEBF9mJ dXkb8NJF1NuwEskNX6xpVYHr60zRoJj14z4iiAoKqILEWH8Vw+tooaldMqH/eJ6kcBYz oOIq9M765MLy72xq5//EptULcwg8IuJmuslHI8urbZA+Yc0sLDk9U72xma9F26ItOq3n 49BAn66C/+K8LSSKWzAxPaUrIO5lQkxK1a38N3iQ30sZ9puvINtuoMiS0ESPGfXaXf2+ fW/g== X-Gm-Message-State: AOAM531lVMRMXgwWxWnjDr/zLHbqjZ7EmhEEeMc0RySghHpGedSyORzx G+yNvUtVNBZATGzuIWErP7yAyfiJ5lS3Ow== X-Google-Smtp-Source: ABdhPJwE1O+J5U/hBDLeB1IfkSOoMWHLCKM1sxup7trg5oRqS2LmajnzcZkJ/+L495uDEQcp5l8B/w== X-Received: by 2002:a2e:9e1a:: with SMTP id e26mr31972268ljk.265.1626886555868; Wed, 21 Jul 2021 09:55:55 -0700 (PDT) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com. [209.85.167.45]) by smtp.gmail.com with ESMTPSA id t7sm2244538ljc.81.2021.07.21.09.55.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 09:55:55 -0700 (PDT) Received: by mail-lf1-f45.google.com with SMTP id 8so4134959lfp.9 for ; Wed, 21 Jul 2021 09:55:55 -0700 (PDT) X-Received: by 2002:a05:6512:260a:: with SMTP id bt10mr26860515lfb.636.1626886555073; Wed, 21 Jul 2021 09:55:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erick Ochoa Date: Wed, 21 Jul 2021 18:55:43 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: tree decl stored during LGEN does not map to a symtab_node during WPA To: Richard Biener Cc: Jan Hubicka , GCC Development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Wed, 21 Jul 2021 16:55:59 -0000 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. 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?