From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by sourceware.org (Postfix) with ESMTPS id 97B323858C78 for ; Fri, 14 Apr 2023 21:38:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 97B323858C78 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-pj1-x102a.google.com with SMTP id f2so11237088pjs.3 for ; Fri, 14 Apr 2023 14:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681508287; x=1684100287; 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=N/FcT4pl6Ynkwk03mK31qPiKFl99s1vV6szwYx70L8g=; b=PcTJerCCSV99ZHQJiFPtgVFKTioxUHDCx0DVIqHdoajhXQwa6fanP1SlzV4bBCPAGE jU2umR6H83a/bcQGsSCNO0ZcEfv6rSNCwcEY/+3lWjur83taaNJKDTRH0Gwnwqt+PmWT BrfVsugfmLJ+wV4zQEzr6Hd6WnUTRkrO66P2FUDWuLqRnlPa36Q7w4QMBa2LQ4X3aZNI cWTKw8ZfJvplg3ZfVweq2goFxdoljo0WNccFZqaitM+kpTBT95m3/XHoDOO3/8xxc03j g1O3zXNkeFm0p2pvuAT8J+gSwzz+AVtgNnHGx8HezFL7RsxZ7PbpMarELC681Z2mJWgd AQrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681508287; x=1684100287; 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=N/FcT4pl6Ynkwk03mK31qPiKFl99s1vV6szwYx70L8g=; b=gr29YsMcR6M8lGpJAzHNtrU67WdWBzX45JeH+MbQJWP3Bcs8BYmMAvMD6uzKtyFzh6 77nEcO4YOd8+i89Z1uPDVl3/8RCOwYtjumjY4E91Yz0g08t/GpOaifKzBXJVbVG3ABHC /Bb4yQoy/EUtZ7ThD+Mno0F50tZg0EmdqosUyXGXfHYfwD0/uIQzR4WS2rXih8EAwzN2 Dy/SvZEAneOb1O8j9CBxzazIAC9OCnXHoor/Mw0KTVUaAJrs5WuUlV9V50x27ooHEf8K l2HhCRpQgEnM4UcWDgUoynnMCBMUgl2XfCRj2C6oReaFfh48LTPTdPYnJRKbT6sAr794 oFZg== X-Gm-Message-State: AAQBX9ePr6Z1Qy27vQkoBx4vyXv7mGgJFWJnHse/pCE2FGU9JO24dnaN bgv2sTWjA27dAcej7oU9OdhY/qThx6Q= X-Google-Smtp-Source: AKy350Y3WMcG7mXzYHFpOyZetBYNGambsfVFyjtbE46IlqD/m0YjJQrP39EHYk1455Qb5fSGIb+2Zw== X-Received: by 2002:a05:6a20:441e:b0:ee:d553:5cee with SMTP id ce30-20020a056a20441e00b000eed5535ceemr108856pzb.16.1681508286837; Fri, 14 Apr 2023 14:38:06 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id w2-20020a63c102000000b0051806da5cd6sm3160497pgf.60.2023.04.14.14.38.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Apr 2023 14:38:06 -0700 (PDT) Message-ID: Date: Fri, 14 Apr 2023 15:38:04 -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] In the ready lists of pipeline, put unrecog insns (such as CLOBBER, USE) at the latest to issue. Content-Language: en-US To: Jin Ma via Gcc-patches , Jin Ma , "kito.cheng@sifive.com" , "kito.cheng@gmail.com" , "palmer@dabbelt.com" , "ijinma@yeah.net" , richard.sandiford@arm.com References: <20230323080734.423-1-jinma@linux.alibaba.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_MANYTO,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 3/27/23 11:01, Richard Sandiford wrote: > Jin Ma via Gcc-patches writes: >> Unrecog insns (such as CLOBBER, USE) does not represent real instructions, but in the >> process of pipeline optimization, they will wait for transmission in ready list like >> other insns, without considering resource conflicts and cycles. This results in a >> multi-issue CPU architecture that can be issued at any time if other regular insns >> have resource conflicts or cannot be launched for other reasons. As a result, its >> position is advanced in the generated insns sequence, which will affect register >> allocation and often lead to more redundant mov instructions. > > Is it the clobber rather than the use case that is causing problems? > I would expect that scheduling a use ASAP would be better for register > pressure, since it might close off the associated live range and so > reduce the number of conflicts. Agreed. Issuing USES as soon as possible seems advisable from a register pressure standpoint. A clobber can close off a range as well, but I suspect that is the exception rather than the norm. > > I.e. is the problem that, when a live range starts with a clobber, > the current code will tend to move the clobber up and so extend > the associated live range? If so, that sounds like something we > should address more directly, for two reasons: Agreed as well. I would expect the normal case for clobbers is that deferring them as late as possible is best as I would expect they typically open a live range. > > (1) We should try to prevent clobbers that start a live range from being > moved up even if first_cycle_insn_p. Yes. > > (2) Clobbers can also be used to close off a live range, which is useful > if a pseudo is only written to in parts. The current behaviour is > probably better for those clobbers. I thought these sequences started with a clobber, then the component sets. In which case the clobber isn't closing a live range, but opening one and deferring it is advisable. jeff