From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 6A22A3858D32 for ; Thu, 6 Apr 2023 10:15:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6A22A3858D32 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: by mail-wr1-x42b.google.com with SMTP id e18so38959614wra.9 for ; Thu, 06 Apr 2023 03:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1680776153; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1vk1+ygWH61YskiPKtTf+wvM6Dwm1XPGxViPRssGAWc=; b=O79LdlkOSI5JDiyHtuDW1CD/1o9/8Of6/RBDCDkflsrdU9PJhwKiZFsoIvoaJKIbEg e1RQleJbx8gwYmpVfH4Thq2+4v4HEuObVTVkaQhAkevIqmFddXrMJZXXtYrAWJPbrMj6 yC6QSjcXPvPqpu+wepAv2YnxuPUuAu4JxkJOctHjI6gaMPQNtgu6/RaegPpcpsH9UEed PZ9J/xR8zL5wkwwfeZsTWVDJTuriI0urU2tiAIezCozs3kkuUkZ6Hou3xFOz8GoRhALR fqHI76JZv33dAXEuVluk+ZFrsEhWbfQEBmgqbhaDUhjh8fHSBycK5xEMaNWBkE0enSil Sdmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680776153; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1vk1+ygWH61YskiPKtTf+wvM6Dwm1XPGxViPRssGAWc=; b=pY3lVO1r744otZWDt+IBB3BaPrzZoAwYAO/cHjU11xh2fKbnxIMFqqUp1tGS38rhIp TbrJBa9CUw+gvK7U8v45/+xJB8vnfpp2YucCpLEIFvx0fNHbhA2V+qYCMEjbn5L8nhkN zNeJGOUWc6ceiV3pRIhsZmu1XflftfIqVzP6GJ96YcGWMDyAlK5J0xbMpH03PFn4Zhfl iFeBXg4td1P18MWE6dqCFe7npYbcDnbamo/Q87rLIgjJwvJ5/Y7vefLapdoeI0FITrQx q8mFqCJXFKiW3G0ybPvgfO2ZTjvg3fNTUbRKLcJX2DuyzKE9erEsdJ+F0/FTZzBb4ccB bz5A== X-Gm-Message-State: AAQBX9cW3XWB/2qJXYYKigoXBYwd9GwvdbZfROPviKeYnSQLrPsFmtVj 4/E4kmpuOFWBXQpuwHEGRvo7pw== X-Google-Smtp-Source: AKy350b6AqueaBPgB40xKQWhjbksKFVs9+osHR+w4plBL9fLJ4D8JgJriLn7C5047xG5/RfO6SxT3Q== X-Received: by 2002:a5d:4745:0:b0:2ce:a835:83d4 with SMTP id o5-20020a5d4745000000b002cea83583d4mr3858645wrs.27.1680776152799; Thu, 06 Apr 2023 03:15:52 -0700 (PDT) Received: from fomalhaut.localnet ([2a01:e0a:8d5:d990:e654:e8ff:fe8f:2ce6]) by smtp.gmail.com with ESMTPSA id t4-20020a5d6a44000000b002e558f1c45fsm1336922wrw.69.2023.04.06.03.15.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Apr 2023 03:15:52 -0700 (PDT) From: Eric Botcazou X-Google-Original-From: Eric Botcazou To: Jeff Law Cc: Jakub Jelinek , Richard Biener , Richard Sandiford , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] dse: Handle SUBREGs of word REGs differently for WORD_REGISTER_OPERATIONS targets [PR109040] Date: Thu, 06 Apr 2023 12:15:51 +0200 Message-ID: <2876279.e9J7NaK4W3@fomalhaut> In-Reply-To: <612b6215-8bc3-1174-a475-4315176bfe1c@gmail.com> References: <612b6215-8bc3-1174-a475-4315176bfe1c@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: > Originally I didn't really see this as an operation. But the more and > more I ponder it feels like it's an operation and thus should be subject > to WORD_REGISTER_OPERATIONS. > > While it's not really binding on RTL semantics, if we look at how some > architectures implement reg->reg copies, they're actually implemented > with an ADD or IOR -- so a real operation under the hood. > > If we accept a subreg copy as an operation and thus subject to > WORD_REGISTER_OPERATIONS then that would seem to imply the combine is > the real problem here. Otherwise dse is the culprit. Yes, I agree that there is an ambiguity for subreg copy operations. At some point I tried to define what register operations are and added a predicate to that effect (word_register_operation_p ); while it returns true for SUBREG, it's an opt-out predicate so this does not mean much. I don't think that DSE does anything wrong: as I wrote in the PR, defining WORD_REGISTER_OPERATIONS should not prevent any particular form of RTL. I therefore think that the problem is in the combiner and probably in the intermediate step shown by Jakub: "Then after that try_combine we do: 13325 record_value_for_reg (dest, record_dead_insn, 13326 WORD_REGISTER_OPERATIONS 13327 && word_register_operation_p (SET_SRC (setter)) 13328 && paradoxical_subreg_p (SET_DEST (setter)) 13329 ? SET_SRC (setter) 13330 : gen_lowpart (GET_MODE (dest), 13331 SET_SRC (setter))); and the 3 conditions are true here and so record value of the whole setter. That then records among other things nonzero_bits as 0x8084c." That's a recent addition of mine (ae20d760b1ed69f631c3bf9351bf7e5005d52297) and I think that it probably abuses WORD_REGISTER_OPERATIONS and should either be reverted or restricted to the load case documented in its comment. I can provide testing on SPARC if need be. -- Eric Botcazou