From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 10B013858D3C for ; Fri, 9 Jun 2023 23:40:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 10B013858D3C 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-x431.google.com with SMTP id d2e1a72fcca58-65131e85be4so2434899b3a.1 for ; Fri, 09 Jun 2023 16:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686354038; x=1688946038; 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=ofY5W9nSXxSazxC+w9516mmSUWwD6nkV01AlSGkiRgw=; b=QpLai8QBTCsAWNJFUvLQoPd6lMrGk/2rWgA0G045UPr1hEdsNIguQdgRIGOkaARX4C Z4vUb9jG3oNx0SClgwkaEPBQ/iYorGL140sdNIizavILrr1rkA1jWwSRTJtI8d9iTK+o Yl0dxUqAjpKRj93YUwwcoWu5UK4MH31acb5qRhMSJPLcbDPgxgEOqBegdhj1DNe2BphI 8YsbhPjiNAEHW40DPjahavIgTbB0Ty/8fm/zW9nx00KDM8dZRc4L41YgRvczi7pQGERm tqCvO/tSBp9/B5rag5WCXg3OLLrU5cFGFDnELPqPuRGtyCihIIUyAKqAr6Zv6AdXOdNq rnOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686354038; x=1688946038; 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=ofY5W9nSXxSazxC+w9516mmSUWwD6nkV01AlSGkiRgw=; b=VgnDhuWDbSdSmeqtJx5rFAdSTKV61Y4i8WsV/6npD5xNFcTFbTfJsvxU5MlOZDXbX1 Jmg+oquHeDvDhRWZRjCZYHlLrchpHO8kcKfl9nUO6yZ9FSVgXiH4MKcXCRk2tMsccJUS kljCthil9KpgMhHMh/go7lYdZr6v6pSgAgQXSN1uWA8QmD8wfygQX28yxTnmdAEd6smC ITKKvd62DRSfS+v789R3fMqLZSvqlknKKeSkkbYI3aMvlQC1zoIds7rzZhwDKkholLe5 4rrT6jZ3Wj3eK4iON2jPI2iUcSNP2W5Xr+45TU79n5okn1kv54h39S8QOPV3z7rFc1Rb 8eXg== X-Gm-Message-State: AC+VfDwAlVOwSbLtUUDT9Ao1ZX0NOA3dY0S9OBtMe/xW4ADJyOGZ0ylD GqqWI8EMIPwyFzb2CchxB08= X-Google-Smtp-Source: ACHHUZ67VwDS10E+ogFM1QXvwKUpU5ZILy4uDpvyNm3bfxHi6W26GrVHKt8DVVI1umlkL9SmZq3gOQ== X-Received: by 2002:aa7:8890:0:b0:657:e9ae:e022 with SMTP id z16-20020aa78890000000b00657e9aee022mr3501657pfe.5.1686354037692; Fri, 09 Jun 2023 16:40:37 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id x25-20020a62fb19000000b0063afb08afeesm3150726pfm.67.2023.06.09.16.40.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jun 2023 16:40:36 -0700 (PDT) Message-ID: Date: Fri, 9 Jun 2023 17:40:35 -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 pipeline, UNRECOG INSN is not executed in advance if it starts a live range. Content-Language: en-US To: Jin Ma , gcc-patches@gcc.gnu.org Cc: richard.sandiford@arm.com, kito.cheng@gmail.com, christoph.muellner@vrull.eu, jinma.contrib@gmail.com References: <20230529105120.1703-1-jinma@linux.alibaba.com> From: Jeff Law In-Reply-To: <20230529105120.1703-1-jinma@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,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/29/23 04:51, Jin Ma wrote: > 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. > > A simple example: > https://github.com/majin2020/gcc-test/blob/master/test.c > This is a function in the dhrystone benchmark. > > https://github.com/majin2020/gcc-test/blob/0b08c1a13de9663d7d9aba7539b960ec0607ca24/test.c.299r.sched1 > This is a log of the pass 'sched1' When issue_rate == 2. Among them, insn 13 and 14 are > much ahead of schedule, which risks generating redundant mov instructions, which seems > unreasonable. > > Therefore, I submit patch again on the basis of the last review opinions to try to solve > this problem. > > This is the new log of shed1 after patch is added. > https://github.com/majin2020/gcc-test/commit/efcb43e3369e771bde702955048bfe3f501263dd > > gcc/ChangeLog: > > * haifa-sched.cc (unrecog_insn_for_forw_only_p): New. > (prune_ready_list): UNRECOG INSN is not executed in advance if it starts a > live range. > --- > gcc/haifa-sched.cc | 44 +++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 39 insertions(+), 5 deletions(-) > > diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc > index 2c881ede0ec..205680a4936 100644 > --- a/gcc/haifa-sched.cc > +++ b/gcc/haifa-sched.cc > @@ -765,6 +765,23 @@ real_insn_for_shadow (rtx_insn *insn) > return pair->i1; > } > > +/* Return true if INSN is unrecog that starts a live range. */ I would rewrite this as /* Return TRUE if INSN (a USE or CLOBBER) starts a new live range, FALSE otherwise. */ > + > +static bool > +unrecog_insn_for_forw_only_p (rtx_insn *insn) I would call this "use_or_clobber_starts_range_p" or something like that. > +{ > + if (insn && !INSN_P (insn) && recog_memoized (insn) >= 0) > + return false; I would drop the test that INSN is not NULL in this test. There's no way it can ever be NULL here. If you really want to check that, then I'd do something like gcc_assert (INSN); Instead of checking it in that condition. > @@ -6320,11 +6337,28 @@ prune_ready_list (state_t temp_state, bool first_cycle_insn_p, > } > else if (recog_memoized (insn) < 0) > { > - if (!first_cycle_insn_p > - && (GET_CODE (PATTERN (insn)) == ASM_INPUT > - || asm_noperands (PATTERN (insn)) >= 0)) > - cost = 1; > - reason = "asm"; > + if (GET_CODE (PATTERN (insn)) == ASM_INPUT > + || asm_noperands (PATTERN (insn)) >= 0) > + { > + reason = "asm"; > + if (!first_cycle_insn_p) > + cost = 1; > + } > + else if (unrecog_insn_for_forw_only_p (insn)) > + { > + reason = "unrecog insn"; > + if (!first_cycle_insn_p) > + cost = 1; > + else > + { > + int j = i; > + while (n > ++j) > + if (!unrecog_insn_for_forw_only_p (ready_element (&ready, j))) > + break; > + > + cost = (j == n) ? 0 : 1; > + } Why do you need a different cost based on what's in the ready list? Isn't the only property we're looking for whether or not the USE/CLOBBER opens a live range? Jeff