From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by sourceware.org (Postfix) with ESMTPS id D8E85385840A for ; Wed, 10 Jan 2024 09:56:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D8E85385840A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D8E85385840A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704880596; cv=none; b=WwBeeeOCb7tMllGPm61+2tSdL99oEMKohNXcGyTCszuIpLnJ8ZDitqdoA/OseYyUVh/4Ga7wMeIIVBXZNSZmvOEp17NsUXj6GGcfafi/fb9PSNwZmECOMN+NMfX7NPdbIlmIvwGG5GhZNmhQ6TzSotZjVb2RWRZdzWbUCz19OjU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704880596; c=relaxed/simple; bh=I4Ru3hwI0grMiuuXLhcedhqgsexEJV0wg8dgQtp3Rg8=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=roTSSynBgdyj86875ZWiCSnuWdbXImBKN4Unc+TPCsCXY3KBOYXwIY87OMKUClJNgvpoo3vGr2Eib3Ez34dU8E3TUWThEZGyjO2F9i2nP60IVyBO3E/LWwGVHNBdBJ/tjuecOl4B8wSpFOPe0n4Cxiy5W05SckSTPIFz3MkzwL4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.4.150] (unknown [10.168.4.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id C2CD921C43; Wed, 10 Jan 2024 09:56:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1704880592; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jo0kpH46ZiWU1Wrw9r+hHn1BwtEwZLDTX+s8HgNBjwU=; b=aC9EykGBmtrvFaMGRzpzb8fArlxe7Zs3WPUIqeg5bPwuEtJEeSS3F5bZPS5C47EG813hvO OJGtkD+2ev2TO71kKavLejYxzXz32okm+jjk62b7JTOKUURzKgUaSNvwR0zoJl6rBjOYWe EAgDUfGYF32HfLLMl9sYMgjkajeL6Xk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1704880592; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jo0kpH46ZiWU1Wrw9r+hHn1BwtEwZLDTX+s8HgNBjwU=; b=j4Mr/k2GD3B0vOTNhe/uohFKZgbkapGFRPY1OAQb93F2oOsV5TXBELMSkI/dFnczFmHO9D xxroHU8XAHAFHPCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1704880592; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jo0kpH46ZiWU1Wrw9r+hHn1BwtEwZLDTX+s8HgNBjwU=; b=aC9EykGBmtrvFaMGRzpzb8fArlxe7Zs3WPUIqeg5bPwuEtJEeSS3F5bZPS5C47EG813hvO OJGtkD+2ev2TO71kKavLejYxzXz32okm+jjk62b7JTOKUURzKgUaSNvwR0zoJl6rBjOYWe EAgDUfGYF32HfLLMl9sYMgjkajeL6Xk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1704880592; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jo0kpH46ZiWU1Wrw9r+hHn1BwtEwZLDTX+s8HgNBjwU=; b=j4Mr/k2GD3B0vOTNhe/uohFKZgbkapGFRPY1OAQb93F2oOsV5TXBELMSkI/dFnczFmHO9D xxroHU8XAHAFHPCA== Date: Wed, 10 Jan 2024 10:51:32 +0100 (CET) From: Richard Biener To: Jakub Jelinek cc: Martin Jambor , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] sra: Partial fix for BITINT_TYPEs [PR113120] In-Reply-To: Message-ID: <9109o45p-54q0-8630-4r29-0s7149rn22q8@fhfr.qr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Level: Authentication-Results: smtp-out1.suse.de; none X-Spamd-Result: default: False [-4.30 / 50.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,tree-sra.cc:url]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; BAYES_HAM(-3.00)[100.00%] X-Spam-Level: X-Spam-Score: -4.30 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,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 List-Id: On Wed, 10 Jan 2024, Jakub Jelinek wrote: > 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? LGTM, see below for a question. > 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. I think SRA has a size limit, --param sra-max-scalarization-size-O{size,speed}, not sure if that is all or the one that's hit. > 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. > > --- 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)); I suppose we don't exactly need to preserve BITINT-ness, say if root->size fits the largest supported integer mode? It's OK as-is for now. > + 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); > +} > > Jakub > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)