From patchwork Mon Feb 12 17:46:57 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 1897876 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=SC1Nn7zG; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TYX3J2mmfz23hM for ; Tue, 13 Feb 2024 04:47:24 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3AB333858401 for ; Mon, 12 Feb 2024 17:47:22 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 1C3253858C98 for ; Mon, 12 Feb 2024 17:47:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1C3253858C98 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 1C3253858C98 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=1707760025; cv=none; b=D0GsCm7KDAJqjAufdlwgiZwh0xbaN0aVPBrrY7VHaZpBFrBC9fnV6IIpN6fA1LE0MOlf+T17pFbk+sEft7Hx+EHS4fVOle+8TmNCOtmIzol3tEU1ofUdYRIrtCw26iBfCpJ0tN0cNj53gX1tG8vEwnWwJeue0ysVay4/j8H56gg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707760025; c=relaxed/simple; bh=c6MV0Ikh0wd6fbBhe0RzMrVeCwaftXzJHuMwuOIHE9I=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=w0LbqkfL30iQk4GU+cs6isr+YUnsL6rL7PhG88L/HqbbgH+BqVY85UlVJ6RSQiBdc1YjbNMnMtZS/rbtfJzpiJVadcX1HVd/bgO9920QNZgZ+0gnQQBolDc11zpcreVMxamhagEHwSH0sr39ebei3JkPlDGx+j3mE7HnWl3E3sE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707760022; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=vMo5VbxXzlnFP8+aj2KqP2jvOAEsrjot7zn7BOHIVn8=; b=SC1Nn7zGfe8uSAZCKC0HpYsAEe2nx9GAR1B7LJpfk5J7WbeC/NxMe0bv94mh3QPQEhB738 pniWMx3UTgeK1OPFNGwmEmlyo/mF6qXF0KrvJGCKNVK94xXh8bHYtDQDZYAMT5k0HMfw9P PKRyfGQjMNrzwNeSGsVDwIzdysA0vYc= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-_5wltUxFOz2hxMEEBLiq6A-1; Mon, 12 Feb 2024 12:47:01 -0500 X-MC-Unique: _5wltUxFOz2hxMEEBLiq6A-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6F1C0299E753; Mon, 12 Feb 2024 17:47:01 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 33294492BC9; Mon, 12 Feb 2024 17:47:01 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 41CHkwwY2671607 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 12 Feb 2024 18:46:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 41CHkvOi2671606; Mon, 12 Feb 2024 18:46:57 +0100 Date: Mon, 12 Feb 2024 18:46:57 +0100 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions multiple of limb_prec [PR113849] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Hi! handle_cast handles the simple way all narrowing large/huge bitint to large/huge bitint conversions and also such widening conversions if we can assume that the most significant limb is processed using constant index and both lhs and rhs have same number of limbs. But, the condition whether we can rely on the most significant limb being processed using constant index is incorrect. For m_upwards_2limb it was correct (m_upwards_2limb then is the number of limbs handled by the loop, so if lhs_type has larger precision than that, it is handled with constant index), similarly if m_var_msb is set (on left shifts), it is never handled with constant idx. But in other cases, like right shifts or non-equality comparisons, or bitquery operations which operate from most significant to least significant limb, all those can handle even the most significant limb in a loop when lhs_type has precision which is a multiple of limb_prec. So, the following patch punts on the optimization in that case and goes for the conditionals in the loop for that case. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-02-12 Jakub Jelinek PR tree-optimization/113849 * gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't use fast path for widening casts where !m_upwards_2limb and lhs_type has precision which is a multiple of limb_prec. * gcc.dg/torture/bitint-58.c: New test. Jakub --- gcc/gimple-lower-bitint.cc.jj 2024-02-10 12:52:10.015925212 +0100 +++ gcc/gimple-lower-bitint.cc 2024-02-12 14:51:58.717472624 +0100 @@ -1267,13 +1267,17 @@ bitint_large_huge::handle_cast (tree lhs the most significant limb is handled in straight line code. If m_var_msb (on left shifts) or if m_upwards_2limb * limb_prec is equal to - lhs precision that is not the case. */ + lhs precision or if not m_upwards_2limb and lhs_type + has precision which is multiple of limb_prec that is + not the case. */ || (!m_var_msb && (CEIL (TYPE_PRECISION (lhs_type), limb_prec) == CEIL (TYPE_PRECISION (rhs_type), limb_prec)) - && (!m_upwards_2limb - || (m_upwards_2limb * limb_prec - < TYPE_PRECISION (lhs_type))))) + && ((!m_upwards_2limb + && (TYPE_PRECISION (lhs_type) % limb_prec != 0)) + || (m_upwards_2limb + && (m_upwards_2limb * limb_prec + < TYPE_PRECISION (lhs_type)))))) { rhs1 = handle_operand (rhs1, idx); if (tree_fits_uhwi_p (idx)) --- gcc/testsuite/gcc.dg/torture/bitint-58.c.jj 2024-02-12 14:58:42.105944347 +0100 +++ gcc/testsuite/gcc.dg/torture/bitint-58.c 2024-02-12 14:44:33.280575269 +0100 @@ -0,0 +1,25 @@ +/* PR tree-optimization/113849 */ +/* { dg-do run { target bitint } } */ +/* { dg-options "-std=c23 -pedantic-errors" } */ +/* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */ +/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */ + +signed char c; +unsigned _BitInt(512) b; + +__attribute__((noipa)) void +foo (unsigned _BitInt(511) a, int *x) +{ + int z = (a << 510) <= b; + *x = z + c; +} + +int +main () +{ + int x; + foo (2, &x); + if (x != 1) + __builtin_abort (); + return 0; +}