From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 9FB283858CDB for ; Wed, 22 Nov 2023 10:08:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9FB283858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9FB283858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700647723; cv=none; b=j4OqswhfgB3NWP4Sy1lNhZLrZRmScQojwaWBX62hs1g7k1AKdXGYI5gSCZI2dFa4/EKLSgZBIAxc7LuJ4KzknAdoSNTKleh0LcdxnBT0A3XPEYfupOYap/LHs9rbW1P9ct/Wj8PbR+eyeZwoJh+wfDSSIbIflUCdILfUJUDDlX0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700647723; c=relaxed/simple; bh=ceq5gx04mjL2hUtMXKFIzh/JYvDwi/5sI+LsTDGbYXQ=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=NtbxiO/PSHUwrejTCmSIP4HRhbotQ3JAjRGgqyD2yQVjLulauebNCw9VywplM+Z8puzWhvp83vUUwYQFKt39OpMP543zLkFuFOFng0FHA7pDOrMXFHQRRHzzUbMvSw74CjPccO4afCKnG2jgBFgVVLsADOaemSb8Q8ayeQTxocg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D0AB31595; Wed, 22 Nov 2023 02:09:28 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 500223F6C4; Wed, 22 Nov 2023 02:08:41 -0800 (PST) From: Richard Sandiford To: "juzhe.zhong\@rivai.ai" Mail-Followup-To: "juzhe.zhong\@rivai.ai" ,gcc-patches , "vmakarov\@redhat.com" , kito.cheng , richard.sandiford@arm.com Cc: gcc-patches , "vmakarov\@redhat.com" , kito.cheng Subject: Re: [PATCH 0/5] Add support for operand-specific alignment requirements References: <1799A3A4235B9025+202311221747530571669@rivai.ai> Date: Wed, 22 Nov 2023 10:08:40 +0000 In-Reply-To: <1799A3A4235B9025+202311221747530571669@rivai.ai> (juzhe's message of "Wed, 22 Nov 2023 17:47:53 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-16.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: "juzhe.zhong@rivai.ai" writes: > Hi, Richard. > > Thanks for supporting register filter in IRA/LRA. > I found it is useful for RVV since we have a set of widen operations that allow source register overlap highpart of dest register group > > For example, if vsext.vf2 v0(dest consume reg v0 and reg v1), v1 (source consume v1 only) > I want to support the highpart overlap above. (Currently, we don't any overlap between source and dest in such instructions). > > So, I wonder whether we can pass "machine_mode" into register filter. Ok, I think it's too late since stage 1 closes. I wonder we can add it in GCC-15? I think adding a mode would add too much overhead. The mode would be the mode of the operand, but with subregs, the mode of the operand can be different from the mode of the RA allocno. So it would no longer be enough for the RA to calculate a bitmask of filters. It would need ro remember which modes are used with those filters. We'd also need to turn the current HARD_REG_SETs into [MAX_MACHINE_MODE] arrays of HARD_REG_SETs. (And there are now more than 256 machine modes for riscv.) The pattern that uses the constraints should already "know" the mode. So if possible, I think it would be better to use different constraints for different modes, using define_mode_attrs. Thanks, Richard