From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id B78C83858407; Thu, 22 Jul 2021 12:23:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B78C83858407 Received: by mail-ed1-x534.google.com with SMTP id ca14so6571136edb.2; Thu, 22 Jul 2021 05:23:47 -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=yNmk3j5YSdGCvrduVQOKHF5BmZ0wSGElqzLUaWGDAb0=; b=RiYxxH6bN/EC4GGCvoAFagEQGDqhgm8n6/UMkk+XzBPTmF6YL4O91WKGo/ZssjmRiv 2d+/1JLVnbJupVuA5vuhYOeBMLrvaVSrCYJywv7J1PPqrqR9PMMgZ3v0LuwswsBRiNXI lt1s8OLbz05T3nSbg2ddFo2dyrGCix4Nv0q8elJG2cfJrY8yRFgiXjFIsGfimdRl0doU pq16vOYhrPQ2/F8YaOhtsC7hJ5cxQeis58WsfFGgh3qKzBB1UfPGICX9AcbMGwvTWp56 AkDZg7Op19EhM0rLQrFE4vLeeJPXjvssOCPk+wX/UKuL8DdEQ1phgs2Waxnf0L/GyAV/ 6SuQ== X-Gm-Message-State: AOAM530OUvfq6SFatYh7VVsJJ07kXO2PsS/eYnR2OOvKRhaGJOKJqutI A8nSr9PvglhcAWYRGJhGxmm5E5lCbu7dK8A6mG/non8f X-Google-Smtp-Source: ABdhPJwYvnj7/ODZMK10vkrrB/jhM6RZAzfmM66k0IpA/hLVtR+qXlT+MXpyLQN+O0oMyXuAkYrcfwsjUu9HNmiY+lY= X-Received: by 2002:a05:6402:31a6:: with SMTP id dj6mr54978413edb.248.1626956626764; Thu, 22 Jul 2021 05:23:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 22 Jul 2021 14:23:36 +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=-3.0 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 12:23:49 -0000 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 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 > 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.