From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by sourceware.org (Postfix) with ESMTPS id EA3DB3858020 for ; Mon, 10 Oct 2022 15:51:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EA3DB3858020 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qk1-x731.google.com with SMTP id j21so4682082qkk.9 for ; Mon, 10 Oct 2022 08:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=e9imAYdtaBJkYodR3NuxpgOMUSiihDkeTGW9t0fgzP0=; b=IFS5yTBGkBwMTnE+8S9GKFMHe0Trk6Hyo34IqWj9PHGkTft8geFXPUW2tnJqZNiOmp Bj+tqCznUXE5fyUFrn/BaEfVlKOBQB+5Wy+PuJyKzeE4opASW30/vT5lOIUnUNdsjhvr ih+W4CUWgsekGp/yqP7WwPkpO5JD8na3OndqVBHN/IeI6st8/GFoULaaWI9pOeJrSvn7 RNE+Q3YWCu5mFTykFl4J842nXfpL5w92USqd51KVLmQSBnnvVLzzXPQsajY6jCZfqHlk CLB0J7+cUjQDCS4nj4WtBs2216o4u14/LKsZzkBFNtalK3Ty9hcpLqOA1/F3DEr/Aabp nepQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=e9imAYdtaBJkYodR3NuxpgOMUSiihDkeTGW9t0fgzP0=; b=k7ozji89S2XJdMvJ/+YdVDV0RkkXUtc2sVj9Dr1NdbPGmITKL0kUusPdqp4DieQvhO lpnF1D7aYdYCXGbBVoRpoaLbKV9t58HMVL8YcJmYWu8zkdkpg8T1Oyp7amCHKQ9jDc+A DU02Y0NCXByi44/MSHKjVjW5TvZLjrl7+B99RUXA3fOit18nR6PT2tKXZq9TL0tOQr5u zbWfuQEUJkx7mTnJ5BbxujkuM0SwMcsITXI7DvhXnWhgM0InN7zGGxW1yo2s7N09gI7n cbhLwOj1mRpSoqWqpAzRvIAhgxFqjqNAtf9pyHwP2wSzcHEMbTIwxM29cwWcI8NB2n7k n9XQ== X-Gm-Message-State: ACrzQf3N6gqKm7I8RdqeFcGgk5aRwwBRDnlMAsFbxEl76L9aFiF6z/1d YgMQ/hPN25Be7Bn+1rELjwBEYMqA6hyU69jTiqs= X-Google-Smtp-Source: AMsMyM6XPQfNC8/uDDKUiUkcTusfAKv43KKJbp2vWgMWR3bSEHiU6N/YeDBoKRGsZxJfs07652lKf1YBrIINrt87dNQ= X-Received: by 2002:a05:620a:14b4:b0:6e7:b940:3a43 with SMTP id x20-20020a05620a14b400b006e7b9403a43mr12494633qkj.81.1665417069410; Mon, 10 Oct 2022 08:51:09 -0700 (PDT) MIME-Version: 1.0 References: <003601d89245$a86f8830$f94e9890$@nextmovesoftware.com> <20220707223833.GA25951@gate.crashing.org> <00fa01d8a0e9$0efdfc60$2cf9f520$@nextmovesoftware.com> <20220726174451.GA25951@gate.crashing.org> <01f501d8a133$56fee8e0$04fcbaa0$@nextmovesoftware.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 10 Oct 2022 08:50:33 -0700 Message-ID: Subject: Re: [PATCH] Add new target hook: simplify_modecc_const. To: Richard Sandiford , Roger Sayle , Segher Boessenkool , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3017.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,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 Thu, Jul 28, 2022 at 5:40 AM Richard Sandiford via Gcc-patches wrote: > > Seems this thread has become a bit heated, so I'll try to proceed > with caution :-) > > In the below, I'll use "X-mode const_int" to mean "a const_int that > is known from context to represent an X-mode value". Of course, > the const_int itself always stores VOIDmode. > > "Roger Sayle" writes: > > Hi Segher, > > It's very important to distinguish the invariants that exist for the RTL > > data structures as held in memory (rtx), vs. the use of "enum rtx_code"s, > > "machine_mode"s and operands in the various processing functions > > of the middle-end. > > FWIW, I agree this distinction is important, with the proviso (which > I think you were also adding) that the code never loses track of what > mode an rtx operand (stored in a variable) actually has/is being > interpreted to have. > > In other words, the reason (zero_extend (const_int N)) is invalid is > not that constant integers can't be extended in principle (of course > they can). It's invalid because we've lost track of how many bits > that N actually has. That problem doesn't apply in contexts where > the operation is described using individual variables (rather than > a single rtx) *provided that* one of those variables says what mode > any potential const_ints actually represent. > > > Yes, it's very true that RTL integer constants don't specify a mode > > (are VOIDmode), so therefore operations like ZERO_EXTEND or EQ > > don't make sense with all constant operands. This is (one reason) > > why constant-only operands are disallowed from RTL (data structures), > > and why in APIs that perform/simplify these operations, the original > > operand mode (of the const_int(s)) must be/is always passed as a > > parameter. > > > > Hence, for say simplify_const_binary_operation, op0 and op1 can > > both be const_int, as the mode argument specifies the mode of the > > "code" operation. Likewise, in simplify_relational_operation, both > > op0 and op1 may be CONST_INT as "cmp_mode" explicitly specifies > > the mode that the operation is performed in and "mode" specifies > > the mode of the result. > > And the mode argument to simplify_const_relational_operation specifies > the mode of the operands, not the mode of the result. I.e. it specifies > the modes of op0 and op1 rather than the mode that would be attached to > the code in "(code:mode ...)" if an rtx were created with these parameters. > > That confused me when I saw the patch initially. Elsewhere in the > file "mode" tends to be the mode of the result, in cases where the > mode of the result can be different from the modes of the operands, > so using it for the mode of the operands seems a bit confusing > (not your fault of course). > > I still struggle with the idea of having CC-mode const_ints though > (using the meaning of "CC-mode const_ints" above). I realise > (compare (...) (const_int 0)) has been the norm "for ever", but here > it feels like we're also blessing non-zero CC-mode const_ints. > That raises the question of how many significant bits a CC-mode > const_int actually has. Currently: > > ... For historical reasons, > the size of a CC mode is four units. > > But treating CC-mode const_ints as having 32 significant bits is surely > the wrong thing to do. > > So if we want to add more interpretation around CC modes, I think we > should first clean up the representation to make the set of valid values > more explicit. (Preferably without reusing const_int for constant values, > but that's probably a losing battle :-)) > > Thanks, > Richard Here is a testcase to show that combine generates (set (reg:CCC 17 flags) (ltu:SI (const_int 1 [1]) (const_int 0 [0]))) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 This new target hook handles it properly. -- H.J.