From patchwork Wed Jan 10 09:43: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: 83732 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A84063857C46 for ; Wed, 10 Jan 2024 09:44:51 +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 00B5F3857C67 for ; Wed, 10 Jan 2024 09:44:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 00B5F3857C67 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 00B5F3857C67 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=1704879847; cv=none; b=xKDZTU7Xgd4IcDbLh79ygAAf+YWfPIWs4VAV7kIOBZvzz4nA8Xlv91+bld1JURGE4pDLrjR5VnEkuzM4ALBFrm6Y1gz4OZXTjqpnTMOWHk4v6/kX9xe5doxCYG/E/fePjLfLSj/R1I5b/bD81X7Iq0fOnjVbGMqXSqXwEPdAXDE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704879847; c=relaxed/simple; bh=KvZmq/EMRVx2Uhh1lX+saiozJXjQ3jVJGg68Uj8yWvE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=bFA+Xx2cfievl+cIltl76FZ+jT2fjuEHVLZKbwBWodoS2+ASmTJGHq5njNfO8kpGIqBRb3OMgSsPdvazojkVFiwDF5A6rvlB9skXrAPuDGBVZfCQRmc9dV3WtInYOObJ8x4LbeL16h3gv5Yipwmv/ZUYwhynPTp62sV7lrK38ww= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1704879843; 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=9j0MDR2cy/SkN0tfz7YIgzCWzM04+cIWppzw99uAWYo=; b=B0JE1lIGfxpYSZ5/bWx0B4gMaxVAU8liDHFZNPIKIe72lZkMct1R4gdmT2o66PThRy1cu9 WYbfb2op9TNzGMuVaIfaoibl9/hJFtWeTDpT4YQJqJkK5s725sQvKiLHPobHCJhdelSnKG OOu7HfMLjhTJJ8jZTw1DK/tckPc4IiE= 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-283-_b-vukOVMYmD9V_73jBnbA-1; Wed, 10 Jan 2024 04:44:01 -0500 X-MC-Unique: _b-vukOVMYmD9V_73jBnbA-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 8EA8385A58F; Wed, 10 Jan 2024 09:44:01 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.92]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 52B07492BC7; Wed, 10 Jan 2024 09:44: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 40A9hwAD379556 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 10 Jan 2024 10:43:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 40A9hvSM379555; Wed, 10 Jan 2024 10:43:57 +0100 Date: Wed, 10 Jan 2024 10:43:57 +0100 From: Jakub Jelinek To: Martin Jambor , Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] sra: Partial fix for BITINT_TYPEs [PR113120] 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.3 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+patchwork=sourceware.org@gcc.gnu.org Hi! As changed in other parts of the compiler, using build_nonstandard_integer_type is not appropriate for arbitrary precisions, especially if the precision comes from a BITINT_TYPE or something based on that, build_nonstandard_integer_type relies on some integral mode being supported that can support the precision. The following patch uses build_bitint_type instead for BITINT_TYPE precisions. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Note, it would be good if we were able to punt on the optimization (but this code doesn't seem to be able to punt, so it needs to be done somewhere earlier) at least in cases where building it would be invalid. E.g. right now BITINT_TYPE can support precisions up to 65535 (inclusive), but 65536 will not work anymore (we can't have > 16-bit TYPE_PRECISION). I've tried to replace 513 with 65532 in the testcase and it didn't ICE, so maybe it ran into some other SRA limit. 2024-01-10 Jakub Jelinek PR tree-optimization/113120 * tree-sra.cc (analyze_access_subtree): For BITINT_TYPE with root->size TYPE_PRECISION don't build anything new. Otherwise, if root->type is a BITINT_TYPE, use build_bitint_type rather than build_nonstandard_integer_type. * gcc.dg/bitint-63.c: New test. Jakub --- gcc/tree-sra.cc.jj 2024-01-03 11:51:35.054682295 +0100 +++ gcc/tree-sra.cc 2024-01-09 19:50:42.911500487 +0100 @@ -2733,7 +2733,8 @@ analyze_access_subtree (struct access *r For integral types this means the precision has to match. Avoid assumptions based on the integral type kind, too. */ if (INTEGRAL_TYPE_P (root->type) - && (TREE_CODE (root->type) != INTEGER_TYPE + && ((TREE_CODE (root->type) != INTEGER_TYPE + && TREE_CODE (root->type) != BITINT_TYPE) || TYPE_PRECISION (root->type) != root->size) /* But leave bitfield accesses alone. */ && (TREE_CODE (root->expr) != COMPONENT_REF @@ -2742,8 +2743,11 @@ analyze_access_subtree (struct access *r tree rt = root->type; gcc_assert ((root->offset % BITS_PER_UNIT) == 0 && (root->size % BITS_PER_UNIT) == 0); - root->type = build_nonstandard_integer_type (root->size, - TYPE_UNSIGNED (rt)); + if (TREE_CODE (root->type) == BITINT_TYPE) + root->type = build_bitint_type (root->size, TYPE_UNSIGNED (rt)); + else + root->type = build_nonstandard_integer_type (root->size, + TYPE_UNSIGNED (rt)); root->expr = build_ref_for_offset (UNKNOWN_LOCATION, root->base, root->offset, root->reverse, root->type, NULL, false); --- gcc/testsuite/gcc.dg/bitint-63.c.jj 2024-01-09 20:08:04.831720434 +0100 +++ gcc/testsuite/gcc.dg/bitint-63.c 2024-01-09 20:07:43.045029421 +0100 @@ -0,0 +1,24 @@ +/* PR tree-optimization/113120 */ +/* { dg-do compile { target bitint } } */ +/* { dg-require-stack-check "generic" } */ +/* { dg-options "-std=c23 -O -fno-tree-fre --param=large-stack-frame=1024 -fstack-check=generic" } */ + +#if __BITINT_MAXWIDTH__ >= 513 +typedef _BitInt(513) B; +#else +typedef int B; +#endif + +static inline __attribute__((__always_inline__)) void +bar (B x) +{ + B y = x; + if (y) + __builtin_abort (); +} + +void +foo (void) +{ + bar (0); +}