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 7EAE4385843A for ; Fri, 10 Feb 2023 17:01:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EAE4385843A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com 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 932DF4B3; Fri, 10 Feb 2023 09:02:05 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 503C73F703; Fri, 10 Feb 2023 09:01:22 -0800 (PST) From: Richard Sandiford To: Tamar Christina Mail-Followup-To: Tamar Christina ,Tamar Christina via Gcc-patches , nd , "rguenther\@suse.de" , "jlaw\@ventanamicro.com" , richard.sandiford@arm.com Cc: Tamar Christina via Gcc-patches , nd , "rguenther\@suse.de" , "jlaw\@ventanamicro.com" Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583] References: Date: Fri, 10 Feb 2023 17:01:21 +0000 In-Reply-To: (Richard Sandiford's message of "Fri, 10 Feb 2023 16:57:28 +0000") 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=-29.4 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP 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: Richard Sandiford writes: > Final pattern statements (those not in DEF_SEQ) always have the same > type and value as the original statements. We wouldn't see mismatched > precisions if we were only looking at final pattern statements. > > Like you say, the 16-bit addition didn't exist before vectorisation > (it was a 32-bit addition instead). So to make things type-correct, > the 32-bit addition: > > A: sum = a + b (STMT_VINFO_RELATED_STMT == A2) > > is replaced with: > > DEF_SEQ: > A1: tmp = a' + b' (STMT_VINFO_RELATED_STMT == A) > A2: sum' = (int) tmp (STMT_VINFO_RELATED_STMT == A) > > (using different notation from before, just to confuse things). > Here, A2 is the final pattern statement for A and A1 is just a > temporary result. sum == sum'. > > Later, we do a similar thing for the division itself. We have: > > B: quotient = sum / 0xff (STMT_VINFO_RELATED_STMT == B2) > > We realise that this can be a 16-bit division, so (IIRC) we use > vect_look_through_possible_promotion on sum to find the best > starting point. This should give: > > DEF_SEQ: > B1: tmp2 = tmp / (uint16_t) 0xff (STMT_VINFO_RELATED_STMT == B) > B2: quotient' = (int) tmp2 (STMT_VINFO_RELATED_STMT == B) > > Both changes are done by vect_widened_op_tree. Eh, I meant vect_recog_over_widening_pattern. Richard