From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6C5773857732 for ; Tue, 14 Nov 2023 00:01:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6C5773857732 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6C5773857732 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699920085; cv=none; b=JXNQ70sjztvReI1N+ENHrzxcY602uFYb7lzNvUP8p8urjn/9ZLuzhnFlDiT+qwOWBgXXsFnkjYozEOG3s18+jtXOW4j9s6v/I9Q9MH+KcmNlwgwXv3A4fuoFP/+8bVicAqspxy4ZRdJTZN85ARaxXtA793DUKnHKvJpvVSxRYZI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699920085; c=relaxed/simple; bh=LTnfySlOBCYLx/AnGnxNm1WDndQ+T36aK3DU1ubXRd4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Bj32wHDHf9He2KmHjdDY/N0K/FtgM0fD6ChhR5Qi0wVyl/IXgrc3LsAsbMb8Q49Dzfx9xXa/4aPatw/47ZPbLjp/Ng7ToUqeqOqYABT63BcUo72XTQsdgxlhJ/K76DM1vgK89vAZ36SlSDAcKgOyjHJF9Ez5PPqsPxf/ebTTAd8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699920074; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tzz5jI4HshqdCUfHt2NAmpb3rMPmy7+H1d0FKRU4Djs=; b=VdR5NFuXRxNQTuBWk5V0VblmJmA8UgQkumdng3filDG7x+o3hCH1msQE8fd/RBddOBq7WO KB0PaGPbod1zSA4RAGzqa6JoXmcs7TVamUon6hVK12fW8JVUWY4D+IY95cdTddOGTNnCNm ami+QdDcYBR836JhYfz9/EF24+RgNFo= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-37-w1Bxo-XMP--LE-0B9yQW3Q-1; Mon, 13 Nov 2023 19:01:12 -0500 X-MC-Unique: w1Bxo-XMP--LE-0B9yQW3Q-1 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-66d91b47f23so51481416d6.2 for ; Mon, 13 Nov 2023 16:01:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699920072; x=1700524872; 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=tzz5jI4HshqdCUfHt2NAmpb3rMPmy7+H1d0FKRU4Djs=; b=tuW2wBUR8Fi4wqnq+B+m+LmRTFh5uC2u4SHuzbTAh2a69ba6cf6ZVMKFmlg6HXcPDI Z5cTuBNfL8T42vJjDlMclBVcdRPeJWold7iYHyreIgDqwLKN3nGWdDHt5vuZfULJFVx4 L/7ru5N23HcclHur8xIImzpwUD49QoBKUGi45bmX78iQ4ymt4plz6NeO1u0sha37eMQa amOHlczkRK43+CEhOpoA91qS+qCxSmH+rbedHhBJFdtnpAbZIbps/WqrUhRaa67MflMw ngMMpOd++bNWLVdWP7lELOqeue043/DH8MqEMpGX+0LHxQQCeJzpCfPBjjeDXybM1UT/ kqgA== X-Gm-Message-State: AOJu0YyzTP2YxGJ09petyGpsBUMBigsn/KET2j+yOH6nAaB0tDoMOW/B v22EUAEGJvXjccyaVMA+pDLU/y42Kno2shJpt8yZ5dYbanwiUvzNtNfdoPu1Dr3NzAfBQ9/0cVE xhl5No//ZnjKqWtlQ1Q== X-Received: by 2002:a05:6214:5194:b0:65a:fe1f:3cc2 with SMTP id kl20-20020a056214519400b0065afe1f3cc2mr864716qvb.38.1699920072301; Mon, 13 Nov 2023 16:01:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IEKbYnR82zOUYWbUm6g0eS+3N+jKKy6xUywq/hK4GQqGpy2Am1gQZOG7PsJaJr3ZXbYgTJL6A== X-Received: by 2002:a05:6214:5194:b0:65a:fe1f:3cc2 with SMTP id kl20-20020a056214519400b0065afe1f3cc2mr864691qvb.38.1699920071939; Mon, 13 Nov 2023 16:01:11 -0800 (PST) Received: from [192.168.1.88] (23-233-12-249.cpe.pppoe.ca. [23.233.12.249]) by smtp.gmail.com with ESMTPSA id mz14-20020a0562142d0e00b00670c7fd09cbsm2445706qvb.95.2023.11.13.16.01.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Nov 2023 16:01:11 -0800 (PST) Message-ID: <5777a683-4536-4561-e861-4e53dfd18318@redhat.com> Date: Mon, 13 Nov 2023 19:01:10 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 0/5] Add support for operand-specific alignment requirements To: Richard Sandiford , jlaw@ventanamicro.com, gcc-patches@gcc.gnu.org References: <20231112145229.2924713-1-richard.sandiford@arm.com> From: Vladimir Makarov In-Reply-To: <20231112145229.2924713-1-richard.sandiford@arm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 11/12/23 09:52, Richard Sandiford wrote: > SME has various instructions that require aligned register tuples. > However, the associated tuple modes are already widely used and do > not need to be aligned in other contexts. It therefore isn't > appropriate to force alignment in TARGET_HARD_REGNO_MODE_OK. > > There are also strided loads and stores that require: > > - (regno & 0x8) == 0 for 2-register tuples > - (regno & 0xc) == 0 for 4-register tuples > > Although the requirements for strided loads and stores could be > enforced by C++ conditions on the insn, it's convenient to handle > them in the same way as alignment. > > This series of patches therefore adds a way for register constraints > to specify which start registers are valid and which aren't. Most of > the details are in the covering note to the first patch. > > This is clearly changing a performance-sensitive part of the compiler. > I've tried to ensure that the overhead is only small for targets that > use the new feature. Almost all of the new code gets optimised away > on targets that don't use the feature. > > Richard Sandiford (5): > Add register filter operand to define_register_constraint > recog: Handle register filters > lra: Handle register filters > ira: Handle register filters > Add an aligned_register_operand predicate > > gcc/common.md | 28 ++++++++ > gcc/doc/md.texi | 41 +++++++++++- > gcc/doc/tm.texi | 3 +- > gcc/doc/tm.texi.in | 3 +- > gcc/genconfig.cc | 2 + > gcc/genpreds.cc | 146 ++++++++++++++++++++++++++++++++++++++++- > gcc/gensupport.cc | 48 +++++++++++++- > gcc/gensupport.h | 3 + > gcc/ira-build.cc | 8 +++ > gcc/ira-color.cc | 10 +++ > gcc/ira-int.h | 14 ++++ > gcc/ira-lives.cc | 61 +++++++++++++++++ > gcc/lra-constraints.cc | 13 +++- > gcc/recog.cc | 14 +++- > gcc/recog.h | 24 ++++++- > gcc/reginfo.cc | 5 ++ > gcc/rtl.def | 6 +- > gcc/target-globals.cc | 6 +- > gcc/target-globals.h | 3 + > 19 files changed, 421 insertions(+), 17 deletions(-) > Collecting all occurrence constraints for IRA probably might result in worse allocation (when pseudo is spilled because of this) in comparison with using wider hard reg set and generating reload insns for some pseudo occurrences requiring stricter constraints.  Regional RA mitigates this issue.  In any case IRA changes is an improvement in comparison with using only hard_regno_mode_ok.  Using smaller constraints in certain cases for pseudos spilled after using the biggest constraint is just an idea for further RA improvement for targets using the filters. The only question is it worth to implement. All IRA/LRA/reginfo patches are OK for me.  IMHO other changes are pretty strait forward not to ask somebody to review them. Thank you, Richard.