From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 2F4EC3858D28 for ; Sat, 6 May 2023 18:46:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F4EC3858D28 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-x429.google.com with SMTP id d2e1a72fcca58-6439e6f5a33so1305207b3a.2 for ; Sat, 06 May 2023 11:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683398771; x=1685990771; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jd1US5dgYgZJOqmr1neCyviruw9zo66eGsbP46FbAsE=; b=oTJrQ76Y5rQMoUh8VHkuX8AyNFEyFHIKQvBKV3+PZYMOcCACAsNnEHE1G6KBeDGnvh jnsgw/4X6R2DceIt/yt0scekTJIKSDk7TskAWTS3A5Hh+6GmBo+cpBAasNixGWvDI9Gv Mi3k7HkcYKGMQ9nbtOCwMq1mDLTfo39VUPup/Fcki5zadUDslLa6FAq4xMuxbB2hnGHc Lo+Wv96yU7+SANBhqsbz0wXT6nCHFhXdxCD5dzo4INzHEB9mmciDZpfLSOB/p9e9ivXC gXAUUGbTGwKPsM6QxqMWCXkVvbVObk9SyAYqFzhHb7ybfwULzHJS29fIZD7EFkEQ/lF8 fNqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683398771; x=1685990771; h=content-transfer-encoding:in-reply-to:from:references: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=jd1US5dgYgZJOqmr1neCyviruw9zo66eGsbP46FbAsE=; b=A3CWTamK7ZU074r7+wZtY9/yumlENyd6RVmJQXf5lvBJibuRx/R4IoIdZeO72NXeRQ xRP8nr9wwDbe94/JG/0E9qELmWFFnAv7svwCaOk19bicP8zM1p4EHfO2m7itr/okfbgL 7Ww2X1kzB6oIp3vRjGJGh17ELcPRDW3YzehXsKJWaB2gajJHgPoD1uJ3EavAgkYQOaXH yjqVlXgWA9YmlRDElNqi7rwk2H74i9xqEXmYW2PAna0AFZk9Uu0UgmQYfV+AW4l+MO/f FJ1NGSIUiGTKEwjDSKAw1q1b83z7QvB3Y7/BZXd8CGh7I0NbMZFmY/zuaee++w9rmHMQ jZVg== X-Gm-Message-State: AC+VfDypjI875pg4iFfyUICYK+PlGfReYiFOEAWWoGLvNWOMdpgUAbBM Dkf7OU1AI08QMW5pjQ+z11ICu7uG/6w= X-Google-Smtp-Source: ACHHUZ5zZpyex8GiZAzetAJ9HYq9VoVZPqYmFladq63B3gCwlw9RawkQnNXXNUsN0gduiFU/dlJbpQ== X-Received: by 2002:a05:6a00:a14:b0:63d:47ab:65ed with SMTP id p20-20020a056a000a1400b0063d47ab65edmr8037318pfh.7.1683398771025; Sat, 06 May 2023 11:46:11 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id u14-20020aa7848e000000b0062dba4e4706sm3461740pfn.191.2023.05.06.11.46.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 May 2023 11:46:10 -0700 (PDT) Message-ID: <911b709f-cf84-b9ff-3fb3-90d306d2811a@gmail.com> Date: Sat, 6 May 2023 12:46:09 -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: Roger Sayle , 'GCC Patches' References: <009901d9801a$57573ba0$0605b2e0$@nextmovesoftware.com> From: Jeff Law In-Reply-To: <009901d9801a$57573ba0$0605b2e0$@nextmovesoftware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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/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. > > A concrete example of the observed improvement is PR target/43644. > For the test case: > __int128 foo(__int128 x, __int128 y) { return x+y; } > > on x86_64-pc-linux-gnu, gcc -O2 currently generates: > > foo: movq %rsi, %rax > movq %rdi, %r8 > movq %rax, %rdi > movq %rdx, %rax > movq %rcx, %rdx > addq %r8, %rax > adcq %rdi, %rdx > ret > > with this patch, we now generate the much improved: > > foo: movq %rdx, %rax > movq %rcx, %rdx > addq %rdi, %rax > adcq %rsi, %rdx > ret > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=unix{-m32} with > no new failures. OK for mainline? > > > 2023-05-06 Roger Sayle > > gcc/ChangeLog > PR target/43644 > * lower-subreg.cc (resolve_simple_move): Don't emit a clobber > immediately before moving a multi-word register by parts. > > gcc/testsuite/ChangeLog > PR target/43644 > * gcc.target/i386/pr43644.c: New test case. OK for the trunk. I won't be at all surprised to see fallout in the various target tests. We can fault in fixes as needed. More importantly I think we want as much soak time for this change as we can in case there are unexpected consequences. jeff