From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by sourceware.org (Postfix) with ESMTPS id 70D503839819 for ; Thu, 22 Jul 2021 12:33:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 70D503839819 Received: by mail-lj1-f178.google.com with SMTP id e14so7116182ljo.7 for ; Thu, 22 Jul 2021 05:33:34 -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=eItgKerOD9GYeo9F226ugvMQ16DXBjEyTujnEzrEb2Q=; b=PSOpZgKkN51ks4uSIO3TEvOKhSrEwW7V0m3SMSjbKDNe2EyyqjACyXPdwGwBZFVht+ xZSjdjKCBjP5EgJ2VIaj44gWi+M7Hu0Ttvdz5ubrt5kh9QuB3mk839+QGAnaKLgXEGWa KJxhfTJ+dtsi5CYNbs2jWFoq47uruI8BjwTzfmihfANfqsjbMvUqclnjhDUOKe3fen3A iq+p9bch36c1LlczwvG/Kv3Vuq4I/RaVmRhyj1ek2Dte3uQwIFLbXnzkc8VHIhGQVyY8 zwIyQNqQILJNTZTolP1kcmQz9RSOn2JoQhhXklWBYfHW0m/nNWoKXy+3rVG1bM4tiLW7 4Nrg== X-Gm-Message-State: AOAM530PHIk/LLQFBdlisytMvFpIf3IapIGZWX9jWiajr9VOj0MDrTNJ d2cjPH0Op94fKu+KkCfuiPNBLhgyhcP/4Q== X-Google-Smtp-Source: ABdhPJw8Sj6T6xsKvIdLPMBEu0r7oCuThTo/8IRa5hYs96w5igHuqbx/2bMHWrDo2HXQm48QBGxc3g== X-Received: by 2002:a2e:85d8:: with SMTP id h24mr28928866ljj.365.1626957212668; Thu, 22 Jul 2021 05:33:32 -0700 (PDT) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com. [209.85.208.173]) by smtp.gmail.com with ESMTPSA id x13sm1977222lfr.66.2021.07.22.05.33.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jul 2021 05:33:32 -0700 (PDT) Received: by mail-lj1-f173.google.com with SMTP id e14so7116138ljo.7 for ; Thu, 22 Jul 2021 05:33:32 -0700 (PDT) X-Received: by 2002:a2e:9d59:: with SMTP id y25mr34341435ljj.399.1626957212126; Thu, 22 Jul 2021 05:33:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erick Ochoa Date: Thu, 22 Jul 2021 14:33:20 +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.1 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:33:36 -0000 > > > 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? No. I mean during WPA. On a different e-mail I clarified the following: ``` > > 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 during WPA. ``` > > 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? > The only reference to a varpool encoder is on the Changelog. The only encoder I know of is the symtab_encoder (which I believe should be the same as varpool_nodes and cgraph_nodes are both symtab_nodes). But again, I do not know what you mean by "merged" here, since they have different addresses. > > 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. > Yes, this is what I would like, but I don't see how to detect "merged" function definitions. I can get their cgraphs but as I mentioned for every encoding I decode and dyn_cast all I get is a cgraph holding a different address. What does "merged" concretely mean?