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 E72C03858406 for ; Mon, 22 Nov 2021 11:38:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E72C03858406 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 827791042; Mon, 22 Nov 2021 03:38:56 -0800 (PST) Received: from [10.57.25.214] (unknown [10.57.25.214]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E9E7C3F73B; Mon, 22 Nov 2021 03:38:55 -0800 (PST) Message-ID: <8d593d5f-41a0-6051-0ce0-d72834ecfa25@arm.com> Date: Mon, 22 Nov 2021 11:38:55 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [AArch64] Enable generation of FRINTNZ instructions Content-Language: en-US To: Richard Biener Cc: "gcc-patches@gcc.gnu.org" , Richard Sandiford References: <8225375c-eb9e-f9b3-6bcd-9fbccf2fc87b@arm.com> <70s9nn94-452-5rrr-4458-q6n3qp563652@fhfr.qr> <36e3469a-3922-d49e-4006-0088eac29157@arm.com> <653o8886-3p5n-sr82-9n83-71q33o8824@fhfr.qr> <6c730f35-10b1-2843-cffc-4ed0851380be@arm.com> <85sr96q-o3s-602o-3436-40713n68pp84@fhfr.qr> From: "Andre Vieira (lists)" In-Reply-To: <85sr96q-o3s-602o-3436-40713n68pp84@fhfr.qr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 11:38:59 -0000 On 18/11/2021 11:05, Richard Biener wrote: > > @@ -3713,12 +3713,21 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > trapping behaviour, so require !flag_trapping_math. */ > #if GIMPLE > (simplify > - (float (fix_trunc @0)) > - (if (!flag_trapping_math > - && types_match (type, TREE_TYPE (@0)) > - && direct_internal_fn_supported_p (IFN_TRUNC, type, > - OPTIMIZE_FOR_BOTH)) > - (IFN_TRUNC @0))) > + (float (fix_trunc@1 @0)) > + (if (types_match (type, TREE_TYPE (@0))) > + (if (TYPE_SIGN (TREE_TYPE (@1)) == SIGNED > + && direct_internal_fn_supported_p (IFN_FTRUNC_INT, type, > + TREE_TYPE (@1), > OPTIMIZE_FOR_BOTH)) > + (with { > + tree int_type = TREE_TYPE (@1); > + unsigned HOST_WIDE_INT max_int_c > + = (1ULL << (element_precision (int_type) - 1)) - 1; > > That's only half-way supporting vector types I fear - you use > element_precision but then build a vector integer constant > in an unsupported way. I suppose vector support isn't present > for arm? The cleanest way would probably be to do > > tree int_type = element_type (@1); > > with providing element_type in tree.[ch] like we provide > element_precision. This is a good shout and made me think about something I hadn't before... I thought I could handle the vector forms later, but the problem is if I add support for the scalar, it will stop the vectorizer. It seems vectorizable_call expects all arguments to have the same type, which doesn't work with passing the integer type as an operand work around. Should I go back to two separate IFN's, could still have the single optab. Regards, Andre