From patchwork Sat Dec 2 11:05:13 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 172806 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp1698862vqy; Sat, 2 Dec 2023 03:05:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IEA8Yb4QtSwOnZmaZ/dRp58CDpDjpc8u0hjkCObcxZkdOQ535BchNgBm2JH9VVtJ+UVjn79 X-Received: by 2002:a05:622a:13d4:b0:417:b269:4689 with SMTP id p20-20020a05622a13d400b00417b2694689mr1342145qtk.53.1701515144373; Sat, 02 Dec 2023 03:05:44 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1701515144; cv=pass; d=google.com; s=arc-20160816; b=f7Oxh/5p8gJ3CdQyhkNtSew6BwL/3WHqxQCuONWReBOmr1z6d/m+Ovztg6/JS5i6VZ eC1raY0W2R/dIxzio67Yqoi73MhFcCsDX5jgz1uDKYvDyiLHsgScDiok6k2DEXnWKLph UKfirvcmndReOHONjTLfACBy23E9prIQhzwFql+pROvsHrW6p1M85mispO3HSfILbHfl bQsMlZttWmwJ+LWuq38oZLkhRpnEv725H1bL8d2P9K7RCBbfn6ESYnMuaRhNItFCawaV zqLomqKdXMrPEMC0de9ttQr6xdajsC8ZS203O6jyj3V4Ra4YLlkx44zNat8JP0D7Vz7t 51MA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:reply-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature :arc-filter:dmarc-filter:delivered-to; bh=a2EGOL2KBdTfVrn7l0ibp/vb+LIluiVidOd3536JN/g=; fh=FCjeRajqaQYHMkQtfIia8KT5yBac53mYOLLyJhYG/AY=; b=pAzggdQ9USvuBZvy7tlx0Onv+kk6em1eCovEVgbGX+QvE4n89sUirj5PjD8Pbwwuo/ OVcVhbZ9fb19XxRJi1CX6pFpvF8xBiEj0v0oZW+itreid4RG+pbLvda5vbZN1tQhWYBN IHR1EZWAByBbA1QP4GbJBu8WQ9f1OFA+SaXsBpyKJ0QJgme9jkhab1X7VHjkWpj3PkAO 0GJgzKtux+LynyxE9uZlffsGnp05//JBjjvmbfVEIl+jsCJa7h4xHbVqizZGhiGd/hdN zzLO14xk3lp5rL3PVnQu0GL+N8StUO+B724yfA7+RN8O7Udubg+Dnwaa0A/i9MG3FhEF P8lQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="d/1JeOJq"; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id fx11-20020a05622a4acb00b00419642d586esi5509365qtb.450.2023.12.02.03.05.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 03:05:44 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="d/1JeOJq"; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 25F43386180B for ; Sat, 2 Dec 2023 11:05:44 +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 1777F385840D for ; Sat, 2 Dec 2023 11:05:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1777F385840D 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 1777F385840D 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=1701515121; cv=none; b=BoaoSD5dMaOrpGYE8bjY8Vz54D3z0ah/ITF/ZtHiUiJo1I726RBoXI81jxl89HXzVJ/5YdwsYD3LhbV3JDDYStioEjrSIr0f0edQ2uMm/+AKSG8tbRiLgJP2IV8CWqfLJCN3gMn3aXbJB1QnlmrexUx6RqtGsQzMxq+QYg/fNtQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701515121; c=relaxed/simple; bh=+8qCeyaqo88pe17YXaiBcFNcuocf0cxVPUy6nW9+oKE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=hX+4y8Uc37urEDV2CUBYrJf+ildYMol1IImPGbG6L8K/3TpLtwJnUXBsBsfSl6XlIZsLbLgf94uu+/3PkFdlPInLUv6qm8T3GysysFeQKoHx60TAz/qrDBbiYTYH7zhQhwRxpyRRI5MVWOrqj656s3A5TlWxX6PpedjsD964vqc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701515119; 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=a2EGOL2KBdTfVrn7l0ibp/vb+LIluiVidOd3536JN/g=; b=d/1JeOJqjMqDI/Zs7AzBfP7mdf8PD0fGwj0rhuwnNnqVkBON3doUvObO7l8skBJ347yWVM DPJcfKRhiucWFA2fd6qxniz3SNfVqzPnhqJ1pi5o4xy54gVAWUS9yui+6nUbLAN3IV4alx gvkAe13clA0+8rB+AjFHej4glIhq+vg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-515-Rsi9VkkINBqKDH4nP5pWZw-1; Sat, 02 Dec 2023 06:05:17 -0500 X-MC-Unique: Rsi9VkkINBqKDH4nP5pWZw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 2B733810FC1; Sat, 2 Dec 2023 11:05:17 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E3348C15881; Sat, 2 Dec 2023 11:05:16 +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 3B2B5EJV3605241 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 2 Dec 2023 12:05:14 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 3B2B5Ddb3605240; Sat, 2 Dec 2023 12:05:13 +0100 Date: Sat, 2 Dec 2023 12:05:13 +0100 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] lower-bitint: Fix up lower_addsub_overflow [PR112807] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.4 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_H4, RCVD_IN_MSPIKE_WL, 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+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784167944234043503 X-GMAIL-MSGID: 1784167944234043503 Hi! lower_addsub_overflow uses handle_cast or handle_operand to extract current limb from the operands. Both of those functions heavily assume that they return a large or huge BITINT_TYPE. The problem in the testcase is that this is violated. Normally, lower_addsub_overflow isn't even called if neither the return's type element type nor any of the operand is large/huge BITINT_TYPE (on x86_64 129+ bits), for middle BITINT_TYPE (on x86_64 65-128 bits) some other code casts such operands to {,unsigned }__int128. In the testcase the result is complex unsigned, so small, but one of the arguments is _BitInt(256), so lower_addsub_overflow is called. But range_for_prec asks the ranger for ranges of the operands and in this case the first argument has [0, 0xffffffff] range and second [-2, 1], so unsigned 32-bit and signed 2-bit, and in such case the code for handle_operand/handle_cast purposes would use the _BitInt(256) type for the first operand (ok), but because prec3 aka maximum of result precision and the VRP computes ranges of the arguments is 32, use cast to 32-bit BITINT_TYPE, which is why it didn't work correctly. The following patch ensures that in such cases we use handle_cast to the type of the other argument. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Perhaps incrementally, we could try to optimize this in an earlier phase, see that while the .{ADD,SUB}_OVERFLOW has large/huge _BitInt argument, as ranger says it fits into a smaller type, add a cast of the larger argument to the smaller precision type in which it fits. Either in gimple_lower_bitint, or match.pd. An argument for the latter is that e.g. complex unsigned .ADD_OVERFLOW (unsigned_long_long_arg, unsigned_arg) where ranger says unsigned_long_long_arg fits into unsigned 32-bit could be also more efficient as .ADD_OVERFLOW ((unsigned) unsigned_long_long_arg, unsigned_arg) 2023-12-02 Jakub Jelinek PR middle-end/112807 * gimple-lower-bitint.cc (bitint_large_huge::lower_addsub_overflow): When choosing type0 and type1 types, if prec3 has small/middle bitint kind, use maximum of type0 and type1's precision instead of prec3. * gcc.dg/bitint-46.c: New test. Jakub --- gcc/gimple-lower-bitint.cc.jj 2023-12-01 10:56:45.535228688 +0100 +++ gcc/gimple-lower-bitint.cc 2023-12-01 18:38:24.633663667 +0100 @@ -3911,15 +3911,18 @@ bitint_large_huge::lower_addsub_overflow tree type0 = TREE_TYPE (arg0); tree type1 = TREE_TYPE (arg1); - if (TYPE_PRECISION (type0) < prec3) + int prec5 = prec3; + if (bitint_precision_kind (prec5) < bitint_prec_large) + prec5 = MAX (TYPE_PRECISION (type0), TYPE_PRECISION (type1)); + if (TYPE_PRECISION (type0) < prec5) { - type0 = build_bitint_type (prec3, TYPE_UNSIGNED (type0)); + type0 = build_bitint_type (prec5, TYPE_UNSIGNED (type0)); if (TREE_CODE (arg0) == INTEGER_CST) arg0 = fold_convert (type0, arg0); } - if (TYPE_PRECISION (type1) < prec3) + if (TYPE_PRECISION (type1) < prec5) { - type1 = build_bitint_type (prec3, TYPE_UNSIGNED (type1)); + type1 = build_bitint_type (prec5, TYPE_UNSIGNED (type1)); if (TREE_CODE (arg1) == INTEGER_CST) arg1 = fold_convert (type1, arg1); } --- gcc/testsuite/gcc.dg/bitint-46.c.jj 2023-12-01 18:47:12.460245617 +0100 +++ gcc/testsuite/gcc.dg/bitint-46.c 2023-12-01 18:46:41.297683578 +0100 @@ -0,0 +1,32 @@ +/* PR middle-end/112807 */ +/* { dg-do compile { target bitint } } */ +/* { dg-options "-std=gnu23 -O2" } */ + +#if __BITINT_MAXWIDTH__ >= 256 +__attribute__((noipa)) int +foo (_BitInt (256) a, _BitInt (2) b) +{ + if (a < 0 || a > ~0U) + return -1; + return __builtin_sub_overflow_p (a, b, 0); +} +#endif + +int +main () +{ +#if __BITINT_MAXWIDTH__ >= 256 + if (foo (-5wb, 1wb) != -1 + || foo (1 + (_BitInt (256)) ~0U, -2) != -1 + || foo (0, 0) != 0 + || foo (0, 1) != 0 + || foo (0, -1) != 0 + || foo (~0U, 0) != 1 + || foo (__INT_MAX__, 0) != 0 + || foo (__INT_MAX__, -1) != 1 + || foo (1 + (_BitInt (256)) __INT_MAX__, 0) != 1 + || foo (1 + (_BitInt (256)) __INT_MAX__, 1) != 0 + || foo (1 + (_BitInt (256)) __INT_MAX__, -2) != 1) + __builtin_abort (); +#endif +}