From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 234933858D28 for ; Mon, 8 May 2023 22:03:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 234933858D28 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-pf1-x42d.google.com with SMTP id d2e1a72fcca58-64115e652eeso37941032b3a.0 for ; Mon, 08 May 2023 15:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683583379; x=1686175379; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=pKk/NKDUCVqwDs5MIwDhIIiBXtwG3EBBhu90qE7WYhE=; b=QKvAG5NnxsEGSuwuNYhkhOCWLN+CPKvJL9c6qRAr5/AXQzjA0AUgXNh8DM4n4FGTFe 0edC8IY73D6OllMMjjUdOWEzesYAduw6WRkyYsggc+HC0gUmZ1DKJaVSP2Z9V44ol70X TSv3wYICg4s/uzUQ1nd8W9WLpW2JJ+zn8U6ca/OcnKLszhF0YLwy4BBTtVXJp9G5jjvY OB43ep8SBgDq0OmMECnZGgiEcBbURWrXSleK1PWWsuuJ5Zcuhx7ii6vr37goROdIFiNL yeal9RJmmH6cAy5shOeB2/6wHGZy+i8nqi+ZZkTcRSIYzv6i3LHWpKV5aXvQGiD5BR0o Dzvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683583379; x=1686175379; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pKk/NKDUCVqwDs5MIwDhIIiBXtwG3EBBhu90qE7WYhE=; b=MdgCFMexnjdZ7mrkaFIestaceOPX3+y1VvF2tjSnn5/kv651FPbsBdfYZLTo+9x4dz 4RbkC1GLqeCb/Z50OhjjQT+nsNNKr0RTuDHBJq60V9LUx32gbF+lvdrBD2r8XUHhoKuI I+DCzlVuIyY31EKEifHCunI7rVZwgRIJk6VZkuUPMneKoQes9HPiA7oUMg7LcRi3epe4 mgvna/OjiSvA9rLBiTXluM/UMVZ8IXx5YoRH48M4D1HmVocYc/23BaXx/7pmAS9aUlyP X41e4rrfn5Xq8KQSgpXBhIkQBLULy2UJDFIfS7sBDHEUTFsir0v4HN4RkHeqz43+RUPO +ZBQ== X-Gm-Message-State: AC+VfDyR6FPQS2fPHxIJ8LVdSKf2M4ZkeHQpwp9eZBpRErf4HVidRPYf 558TjvMl+amPe8f1LwLXu1W+TcA1dgg= X-Google-Smtp-Source: ACHHUZ5itRYW1eCN/w4icFKeGe+AZJy3mDMcumcHXeI4E3nJHIGRSkOaBC7NMPrnWMRDRNTc8Qg1nA== X-Received: by 2002:a17:90b:38c2:b0:24d:f67d:7177 with SMTP id nn2-20020a17090b38c200b0024df67d7177mr18237102pjb.20.1683583379009; Mon, 08 May 2023 15:02:59 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id w1-20020a170902904100b001a69c1c78e7sm7699678plz.71.2023.05.08.15.02.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 May 2023 15:02:58 -0700 (PDT) Message-ID: <21650fa7-e181-f87d-1f6e-0127b2291556@gmail.com> Date: Mon, 8 May 2023 16:02:57 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] Don't call emit_clobber in lower-subreg.cc's resolve_simple_move. Content-Language: en-US To: Richard Biener Cc: Roger Sayle , GCC Patches References: <009901d9801a$57573ba0$0605b2e0$@nextmovesoftware.com> <911b709f-cf84-b9ff-3fb3-90d306d2811a@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 5/8/23 00:43, Richard Biener wrote: > On Sat, May 6, 2023 at 8:46 PM Jeff Law via Gcc-patches > wrote: >> >> >> >> On 5/6/23 06:57, Roger Sayle wrote: >>> >>> Following up on posts/reviews by Segher and Uros, there's some question >>> over why the middle-end's lower subreg pass emits a clobber (of a >>> multi-word register) into the instruction stream before emitting the >>> sequence of moves of the word-sized parts. This clobber interferes >>> with (LRA) register allocation, preventing the multi-word pseudo to >>> remain in the same hard registers. This patch eliminates this >>> (presumably superfluous) clobber and thereby improves register allocation. >> Those clobbered used to help dataflow analysis know that a multi word >> register was fully assigned by a subsequent sequence. I suspect they >> haven't been terribly useful in quite a while. > > Likely - maybe they still make a difference for some targets though. > It might be interesting to see whether combining the clobber with the > first set or making the set a multi-set with a parallel would be any > better? Wrapping them inside a PARALLEL might be better, but probably isn't worth the effort. I think all this stuff dates back to the era where we had flow.c to provide the register lifetimes used by local-alloc. We also had things like REG_NO_CONFLICT to indicate that the sub-object assignments didn't conflict. In all it was rather hackish. Jeff