From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by sourceware.org (Postfix) with ESMTPS id AD7343992020 for ; Thu, 22 Jul 2021 12:04:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AD7343992020 Received: by mail-lj1-f177.google.com with SMTP id d17so6975464ljq.12 for ; Thu, 22 Jul 2021 05:04:39 -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=hL757LQVJ9g2ZBZ25wXgjV/3gq9y/+xbX6EeE78b1I4=; b=WC3xVjhGZiIiqAO4tggBk+w6328mJ80RZWHkcM76R/e5z+5N40GRyKMVzoJlcLa1Ox Bn/ko5cvaYB8e0J1t06d0noDS99VmhLjriN/IZfRezXQ+tbY1rNEXiBgm4VWFVJH3I/G g3ZXJ2P/Z+wgpQs7domTEtRpm0DS2eAPFwE7Gmsn5cI7ieOLkpWq0bYifV7NUIBjVai8 O0n5iGXwpwn/ehNUhmI7UgQZVq6FNj60U7ThnBhsGA73jp73zyll4n2hPHbRpv4b2m56 Xds0wQaazgrLuD/+RrXT/DKaFeDbFYFnnSiB3RP6BMr3gSGl8GYn1sVTkdU/Vnf0B4oX N7gQ== X-Gm-Message-State: AOAM532ZMW+WTgCi5TGC8BVZrlq3oFy6MB/AAcbQCvrYIgFs6apzY7PF Ayhp4y0XunGWVwk+CXqNSGyVcph92oDP0w== X-Google-Smtp-Source: ABdhPJyKTkkPDN7+TjbiazLaP5zHm+p+f2HlVZsWqDldT2Eotb06GV5Jn6ueUog6+cYtjFone2Hqkg== X-Received: by 2002:a2e:b803:: with SMTP id u3mr8748717ljo.46.1626955477852; Thu, 22 Jul 2021 05:04:37 -0700 (PDT) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id z19sm1965803lfq.241.2021.07.22.05.04.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jul 2021 05:04:37 -0700 (PDT) Received: by mail-lf1-f44.google.com with SMTP id f30so8163099lfj.1 for ; Thu, 22 Jul 2021 05:04:37 -0700 (PDT) X-Received: by 2002:a19:504d:: with SMTP id z13mr28785795lfj.462.1626955477244; Thu, 22 Jul 2021 05:04:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erick Ochoa Date: Thu, 22 Jul 2021 14:04:25 +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.4 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: Thu, 22 Jul 2021 12:04:41 -0000 > > 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 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. > > > 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 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.