From patchwork Sat Jan 13 09:42:30 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 187881 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp679416dyc; Sat, 13 Jan 2024 01:44:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IH7oDyKQs0f7HVru83m0iXhlm8KxwkYJbSwLmiwNHeU0mLVC1ZziVMx3/s4MIRCeqgCL2EW X-Received: by 2002:a05:620a:6603:b0:783:5273:2191 with SMTP id qf3-20020a05620a660300b0078352732191mr319749qkn.32.1705139078028; Sat, 13 Jan 2024 01:44:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705139078; cv=pass; d=google.com; s=arc-20160816; b=Ck2DU1f/6HYPqdSPMxMQCbNVlmFaq9Nf2gtt1nel8nzbBC9ZjDDFYA8gP+n52ul9JG 04wlrYRexkwpK4Nt32OeUCZUygBtnmJp0seklb3svSR7VU2Rq/Yrz9eSU6ZefYpg9YIs TFg+mBYqA5it5M/qy/n15ASNakabSlPfSAFbz6btuUkuEtFYJb/ETBoGQD/uwVuE8PaH fZLDorShD76KRYKS0Qz2hpG7XfMTejhcGh+5Ke0+FUSPBx0X2idjmCW2pI/oZ7Lrjrih 01uvTc6ctUzhWpKWH2MNoX4zUSNHlUjWbyB0ZmKnr+PkHjJjhdiKlX69OtLTN/IXt5yN Yuiw== 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=/+c9At81eDqwdam3H7TSZWGimMXgYSXSKhYjnbNrf34=; fh=FCjeRajqaQYHMkQtfIia8KT5yBac53mYOLLyJhYG/AY=; b=aJuSAN41rY8t7y6Tvz1+lEtpO4dE68TNDbU3/xRkAHuUQsZIz8a0SO1IGZV+bTeZYR IAhhugVnGkMf9TjRRf97TSN+YQze0i0dhL4iL4NkQvEYtI/5vnshGEgSffSNd1MoIipS aJLgwJmE4C5IjZSqOHutneNSleLTAgTCg2G/3IczMDKzt800WAias5mEKqj+3aoqrSS6 5KSwXOITWXkjjSng0ymTuYllugb7HboboqxvpRKG14CIBpK2dDL8l60Cdm8f2dRaQrwQ bndj7PZb0H247ut65KwcB4xgXnxHzgcRwM6MKqQEMpa7RzJJNVQsfQxKERFFL0o3Yc4c 0wUg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ak6Glcjg; 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 j15-20020a05620a0a4f00b0078132aff7d3si4496822qka.536.2024.01.13.01.44.37 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Jan 2024 01:44:38 -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=Ak6Glcjg; 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 B5C843857C4D for ; Sat, 13 Jan 2024 09:44:37 +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 34EA53857C4D for ; Sat, 13 Jan 2024 09:43:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 34EA53857C4D 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 34EA53857C4D 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=1705139021; cv=none; b=ESeQwFc+Q2oCtl0oJE6M5IJE5ZJ0Tr5abulhZ+YxUaPtc0kNzGR9llBw0ENznCAASjDdlp+2pLukQqQ390slGztQeI0AgjUKwkpQpXo/ZK4E0RIWil6OllqAfPxDnKC8n1AsjszEwvkcy8R+HSsrz01WdBftV6leJ0DfVr0ZAYs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705139021; c=relaxed/simple; bh=LhrQuKQdzhh1hk/NJx1J3kqspE9yF/coXJCtaLwUwVM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=dtJBS0a0/90kdNCVdHQ+/teSZIRGcmPCo5jhPVTt/40bT9xm1EmSCtPLqlJMPQL9wl+c9gKSTtga6c/UaXzLfBjy+Qp6XfWa86jaR02+y00Dx6HF+rFePaUk9pHM3ZrODrEr2Ydu7LmHzrpjmK9CbOQEtMcLJOQLzgVU8vVJ0rM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705139017; 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=/+c9At81eDqwdam3H7TSZWGimMXgYSXSKhYjnbNrf34=; b=Ak6Glcjgj6wHYzh5A7rMkigMIjgfq6f1JjQiW55W4cgxe7fiLp3zZ5HwKffxEucVQS2miu qi0MPiLDUL5sjdEhxvLJtC4yhxGTjsvnySizpB/zocrOTxBZ+m2CMJit0WVRLMY/sTG2/r a/M1TQ4LJPF2CHjA5RjXE/bB3Wu8UsA= 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-581-U6eij-9zOqmSvJX_ibcUSA-1; Sat, 13 Jan 2024 04:43:35 -0500 X-MC-Unique: U6eij-9zOqmSvJX_ibcUSA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 50A5429AB453; Sat, 13 Jan 2024 09:43:35 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.66]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 14DEB1C0652C; Sat, 13 Jan 2024 09:43:34 +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 40D9hWxA2899920 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 13 Jan 2024 10:43:32 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 40D9gUio2899772; Sat, 13 Jan 2024 10:42:30 +0100 Date: Sat, 13 Jan 2024 10:42:30 +0100 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] lower-bitint: Fix up handle_operand_addr INTEGER_CST handling [PR113361] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-5.0 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: 1787967913554958071 X-GMAIL-MSGID: 1787967913554958071 Hi! As the testcase shows, the INTEGER_CST handling in handle_operand_addr (i.e. what is used when passing address of an integer to a bitint library routine) wasn't correct. If the minimum precision to represent an INTEGER_CST is smaller or equal to limb_prec, the code correctly uses m_limb_type; if the minimum precision of a _BitInt INTEGER_CST is large enough such that the bitint is middle, large or huge, everything is fine too. But the code wasn't handling correctly e.g. __int128 constants which need more than limb_prec bits or _BitInt constants which on the architecture are considered small (say have DImode limb_mode, TImode abi_limb_mode and for [65, 128] bits use TImode scalar like the proposed aarch64 patch). Best would be to use an array of 2/3/4 limbs in that case, but we'd need to convert the INTEGER_CST to a CONSTRUCTOR in the right endianity etc., so the code was using mid_min_prec to enforce a middle _BitInt precision. Except that mid_min_prec can be 0 and not computed yet, or it doesn't have to be the smallest middle _BitInt precision, just the smallest so far encountered. So, on the testcase one possibility was that it used precision 65 from mid_min_prec, even when the INTEGER_CST actually needed larger minimum precision (96 bits at least), or crashed when mid_min_prec was 0. The patch fixes it in 2 hunks, the first makes sure we actually try to create a BITINT_TYPE for the > limb_prec cases like __int128, and the second instead of using mid_min_prec attempts to increase mp precision until it isn't small anymore. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-01-13 Jakub Jelinek PR tree-optimization/113361 * gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr): Fix up determination of the type for > limb_prec constants. * gcc.dg/torture/bitint-47.c: New test. Jakub --- gcc/gimple-lower-bitint.cc.jj 2024-01-12 11:23:12.000000000 +0100 +++ gcc/gimple-lower-bitint.cc 2024-01-13 00:18:19.255889866 +0100 @@ -2227,7 +2227,9 @@ bitint_large_huge::handle_operand_addr ( mp = CEIL (min_prec, limb_prec) * limb_prec; if (mp == 0) mp = 1; - if (mp >= (unsigned) TYPE_PRECISION (TREE_TYPE (op))) + if (mp >= (unsigned) TYPE_PRECISION (TREE_TYPE (op)) + && (TREE_CODE (TREE_TYPE (op)) == BITINT_TYPE + || TYPE_PRECISION (TREE_TYPE (op)) <= limb_prec)) type = TREE_TYPE (op); else type = build_bitint_type (mp, 1); @@ -2237,11 +2239,15 @@ bitint_large_huge::handle_operand_addr ( if (TYPE_PRECISION (type) <= limb_prec) type = m_limb_type; else - /* This case is for targets which e.g. have 64-bit - limb but categorize up to 128-bits _BitInts as - small. We could use type of m_limb_type[2] and - similar instead to save space. */ - type = build_bitint_type (mid_min_prec, 1); + { + while (bitint_precision_kind (mp) == bitint_prec_small) + mp += limb_prec; + /* This case is for targets which e.g. have 64-bit + limb but categorize up to 128-bits _BitInts as + small. We could use type of m_limb_type[2] and + similar instead to save space. */ + type = build_bitint_type (mp, 1); + } } if (prec_stored) { --- gcc/testsuite/gcc.dg/torture/bitint-47.c.jj 2024-01-13 00:23:40.627562314 +0100 +++ gcc/testsuite/gcc.dg/torture/bitint-47.c 2024-01-13 00:25:35.571025508 +0100 @@ -0,0 +1,31 @@ +/* PR tree-optimization/113361 */ +/* { dg-do run { target { bitint && int128 } } } */ +/* { dg-options "-std=gnu23" } */ +/* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */ +/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */ + +#if __BITINT_MAXWIDTH__ >= 129 +int +foo (_BitInt(65) x) +{ + return __builtin_mul_overflow_p ((__int128) 0xffffffff << 64, x, (_BitInt(129)) 0); +} + +int +bar (_BitInt(63) x) +{ + return __builtin_mul_overflow_p ((__int128) 0xffffffff << 64, x, (_BitInt(129)) 0); +} +#endif + +int +main () +{ +#if __BITINT_MAXWIDTH__ >= 129 + if (!foo (5167856845)) + __builtin_abort (); + if (!bar (5167856845)) + __builtin_abort (); +#endif + return 0; +}