From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1]) by sourceware.org (Postfix) with ESMTPS id 474243858C56 for ; Thu, 13 Oct 2022 13:15:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 474243858C56 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2BADB116AFA; Thu, 13 Oct 2022 09:15:50 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cb3fyBhG0NeR; Thu, 13 Oct 2022 09:15:50 -0400 (EDT) Received: from free.home (tron.gnat.com [IPv6:2620:20:4000:0:46a8:42ff:fe0e:e294]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id 5FCCD11684B; Thu, 13 Oct 2022 09:15:49 -0400 (EDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 29DDFcQF657785 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 13 Oct 2022 10:15:39 -0300 From: Alexandre Oliva To: Richard Biener Cc: gcc-patches@gcc.gnu.org, Jeremy Bennett , Craig Blackmore , Graham Markall , Martin Jambor , Jan Hubicka , Jim Wilson Subject: Re: [PATCH v2 00/10] Introduce strub: machine-independent stack scrubbing Organization: Free thinker, does not speak for AdaCore References: Errors-To: aoliva@lxoliva.fsfla.org Date: Thu, 13 Oct 2022 10:15:38 -0300 In-Reply-To: (Richard Biener's message of "Thu, 13 Oct 2022 13:38:41 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Oct 13, 2022, Richard Biener wrote: > On Tue, Oct 11, 2022 at 3:33 PM Alexandre Oliva wrote: >> >> On Oct 11, 2022, Richard Biener wrote: >> >> > On Tue, Oct 11, 2022 at 1:57 PM Alexandre Oliva wrote: >> >> >> >> On Oct 10, 2022, Richard Biener wrote: >> >> >> >> > As noted in the Cauldron Discussion I think you should do all >> >> > instrumentation post-IPA only to simplify your life not needing to >> >> > handle inlining of instrumentation >> >> >> >> I looked a bit into that after the Cauldron, and recalled why I wanted >> >> to instrument before inlining: in the case of internal strub, that >> >> introduces a wrapper, it's desirable to be able to inline the wrapper. >> >> > I think if the wrapper is created at IPA time it is also available for >> > IPA inlining. >> >> Yeah, but now I'm not sure what you're suggesting. The wrapper is >> instrumentation, and requires instrumentation of the wrapped >> counterpart, so that can't be post-IPA. > IPA folks can probably explain better but there's IPA (local) > analysis, IPA (global) propagation > and IPA (local) code generation. I think we're miscommunicating. None of these are post-IPA, they're all part of IPA. At first, you'd suggested instrumentation to be made post-IPA, to avoid the trouble of inlining instrumentation. But we *do* want to inline the instrumentation. Now you seem to be suggesting a major revamp of the implementation to integrate it into IPA, rather than post-IPA, while I keep on trying to reconcile that with the initial recommendation of moving it post-IPA. Have you dropped the initial recommendation, and moved on to an unrelated recommendation? If so, I can stop trying to reconcile the unrelated recommendations as if they were related, and focus on the newer one alone. My reasons to not want to integrate strub tightly into IPA infrastructure was that there was no perceived benefit from a tighter integration, and I wasn't sure the feature would be welcome, so I designed something that could be added in a very standalone way, maybe even as a plugin. Maybe there is interest and this decoupling could be reduced, but there'd have to be very compelling reasons to justify undergoing such major reengineering. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about