From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 623CA3858410; Thu, 22 Jul 2021 12:48:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 623CA3858410 Received: by mail-ej1-x634.google.com with SMTP id hc15so8220535ejc.4; Thu, 22 Jul 2021 05:48:32 -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=RrXnxqGPvKkyeK+62NXd2OGdRxoEA+xKr+kXRm2nNUg=; b=GrnLdqpRcapzv7VB1v7WW3a7USTuL1bMiAyrbE1De+U9lBHoZW2Za6mR76E+Sbb0w0 v2Y3omtNPOZw+aKn07mBGGbaHJGtOE4wb24imYl8psHHByhCIFPTk+Q7b5H1lEJnnMq1 Dd5SWA/CaOIIsNSitSzWjNX6vBABD7n4Ar8T1PgdZs1a/wKZRFR/f+RIJXMilWK8vT4/ JIMwo6WucCZ+udvZFz8dw6OV/rO0X7grB7b0Du14IrCYOpHIXQp1K8RG4qoahrHLZPOf XbDcsP7fV0LIK8entF8D1aWp1mVZMvARfpLm140hEGPFc7UjVLdZJGS2cQmtJPJT+fuC T86g== X-Gm-Message-State: AOAM533ppsY55S+08/CcKTiKzISYYnud0VkzDca6d9tKxYPbkoLALzhC wPiq18lcL49d3dq3wVrY4PdKoe3vpd2OigK0Mmqg4nD9 X-Google-Smtp-Source: ABdhPJyB+H6r1jninsY2TI/q3DCi9OvmMZwyJeUJoqZ85/2CheaxBUrL0yuOffBCLhBHydVpsQK4utnVf0SEOIK99mQ= X-Received: by 2002:a17:906:4a0a:: with SMTP id w10mr43238765eju.371.1626958111243; Thu, 22 Jul 2021 05:48:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 22 Jul 2021 14:48:20 +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:48:33 -0000 On Thu, Jul 22, 2021 at 2:33 PM Erick Ochoa wrote: > > > > > 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. But the addresses are at LGEN time? Note the nodes are actually streamed to different instances by input_symtab, then decls are merged (lto_symtab_merge_decls), then I think the IPA pass summaries are read in (to different unmerged instances!), _then_ the symtab merging process starts (lto_symtab_merge_symbols). I think the last step eventually calls the cgraph/varpool removal hook IPA passes registered. It might be that you need a replace hook to do what you want, I think that for example IPA CP encodes references to global vars aka &global as IPA_REF and those are transparently re-written. As said, I think it can be made work but the details, since this is the first IPA pass needing this, can be incomplete infra-structure-wise. Basically you have summaries like 'global = _3' where the should eventually be implicit and the constraints grouped into constraints generated from the respective function body and constraints generated by call stmts (not sure here), and constraints for global variable init. But for the above constraint the point is to make the 'global' references from different LGEN units the same by some means (but not streaming and comparing the actual assembler name). > > > > 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? One node is dropped and all references are adjusted. And somehow IPA passes are notified about this _after_they have read their summaries. Richard.