From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 76FDE3858400 for ; Mon, 18 Oct 2021 09:18:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 76FDE3858400 Received: by mail-ed1-x529.google.com with SMTP id y12so69953884eda.4 for ; Mon, 18 Oct 2021 02:18:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lu05nnNpdScee4Cv0cVW98Q3d2Xs6pjmFZQmnbUfFbU=; b=xfN3BCm54/2y9nKf6XygarkVpyrjUNGZYwWEHkjHSbyhlifyZpWtLYMuqh2I39Yt83 Nlj8fUrak7KEq3wiDzubFsyAVUeYQTiHMq4WFPCGQwOLzUqKgA3hHmtdjkZ2MX/QUxdK xHCbDZx5sHqxsZ0fwJtt78QgLVMzo3u0/0dnIPLfrTTSf5keTdq+Dccj/QYVljF7VzCA NN0BNLsaB/AfLuFjMjqSsix3gmnSkwzx9h0IekP8GwWwae4TEaG0gEa9ec/DJjZRmFDd /hLO97b3fce5BaNbaTUGiWbu/5BMFgcNlsKip5tTnZxyAjK9fLKDQtYMlua+/2AAbSCX oUdA== X-Gm-Message-State: AOAM531dXArc59wGa6jZ1HTZ0MSdMNK8S/Psp/h4tV73OunJ26kCqRPP KePg4BLOdrHR/I2dOkC324grcWjSw8ytpQ7rLbs= X-Google-Smtp-Source: ABdhPJyxiMSa9FqF0NfhXtYdCqH7G/vT1yhANB8psTV3UFd+xUTtYSBabe70NY6mJpQryVfu3kvw8CfkkC3XCyHaKDQ= X-Received: by 2002:a17:907:6d82:: with SMTP id sb2mr22053999ejc.201.1634548689240; Mon, 18 Oct 2021 02:18:09 -0700 (PDT) MIME-Version: 1.0 References: <42A19672-C6EF-4C2F-A826-4CB9EE388B95@gmail.com> In-Reply-To: From: Richard Biener Date: Mon, 18 Oct 2021 11:17:58 +0200 Message-ID: Subject: Re: [PATCH] hardened conditionals To: Alexandre Oliva Cc: Alexandre Oliva via Gcc-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 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-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2021 09:18:12 -0000 On Fri, Oct 15, 2021 at 8:35 PM Alexandre Oliva wrote: > > On Oct 14, 2021, Richard Biener wrote: > > > Yeah, I think that eventually marking the operation we want to preserve > > (with volatile?) would be the best way. On GIMPLE that's difficult, > > it's easier on GENERIC (we can set TREE_THIS_VOLATILE on the > > expression at least), and possibly also on RTL (where such flag > > might already be a thing?). > > Making the expr volatile would likely get gimple to deal with it like > memory, which would completely defeat the point of trying to avoid a > copy. > > RTL has support for volatile MEMs and (user-)REGs indeed, but in order > to avoid the copy, we don't want the pseudo to be volatile, we want > specific users thereof to be. An unspec_volatile would accomplish that, > but it would require RTL patterns to match it wherever a pseudo might > appear. Considering all forms of insns involving conditionals on all > relevant targets, that's far too much effort for no measurable beenefit. > > > > So when going that way doing the hardening on RTL seems easier (if you > > want to catch all compares, if you want to only catch compare + jump > > that has your mentioned issue of all the different representations) > > It's not. RTL has various ways to represent store-flags too. Even now > that we don't have to worry about implicit CC, a single boolean test may > expand to a compare-and-set-[CC-]reg, and then a > compare-and-store-CC-reg, or a single compare-and-set-[non-CC-]reg, and > IIRC in some cases even more than one (pair of) conditionals. > > Compare-and-branches also come in such a multitude of settings. > > It all depends on the target, and I don't really see any benefit > whatsoever of implementing such trivial gimple passes with all the > potential complexity of RTL on all the architectures relevant for GCC, > or even for this project alone. > > > Note that I did not look on the actual patch, I'm trying to see whether there's > > some generic usefulness we can extract from the patchs requirement > > which to me looks quite specific and given it's "hackish" implementation > > way might not be the most important one to carry on trunk (I understand > > that AdaCore will carry it in their compiler). > > It's also simple, no-maintenance, and entirely self-contained. Yes, it is (just having had a quick look most of the functions in the pass lack function-level comments). > A good > example of something that could be implemented as a plugin, except for > command-line options. > > Maybe we could have a plugin collection in our source tree, to hold > stuff like this and to offer examples of plugins, and means to build > select plugins as such, or as preloaded modules into the compiler for > easier deployment. I think this has been suggested before, yes. But if those "plugins" are as self-contained as yours here there's also no reason to not simply compile them in as regular passes (unless they are slightly broken and thus a maintainance burden). Richard. > -- > 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