From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 08AF13858D35 for ; Mon, 22 Nov 2021 11:41:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08AF13858D35 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id EF9001FD26; Mon, 22 Nov 2021 11:41:44 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id E154CA3B89; Mon, 22 Nov 2021 11:41:44 +0000 (UTC) Date: Mon, 22 Nov 2021 12:41:44 +0100 (CET) From: Richard Biener To: "Andre Vieira (lists)" cc: "gcc-patches@gcc.gnu.org" , Richard Sandiford Subject: Re: [AArch64] Enable generation of FRINTNZ instructions In-Reply-To: <8d593d5f-41a0-6051-0ce0-d72834ecfa25@arm.com> Message-ID: 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> <8d593d5f-41a0-6051-0ce0-d72834ecfa25@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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:41:47 -0000 On Mon, 22 Nov 2021, Andre Vieira (lists) wrote: > > 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. We already special case some IFNs there (masked load/store and gather) to ignore some args, so that would just add to this set. Richard.