From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2a07:de40:b251:101:10:150:64:1]) by sourceware.org (Postfix) with ESMTPS id 512C03858D1E for ; Mon, 6 May 2024 09:07:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 512C03858D1E 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 512C03858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714986454; cv=none; b=ppqzSxhVb1jkomXcbft5iEQzqE1uyALIUVu4S1jCTyJcGbEPNjhAVBSyJKCMU/ozLbubwswRsZOXdYYOwEBsHj5cSoWeoWxePtUoYAy1Z5HD95Of0rlN0531XbzK8taZibGT4hheZ/NY9j2mQdZ9eVCNdB6WjIzOlhnDD4ngdpc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714986454; c=relaxed/simple; bh=mbfV2owLX33NJBOhFtDosoDE+/Z4A34TL6URcF3+YM0=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=iSzXE2w0mrr5YXMrukcZa+rvGdmsLk0a671KsOBheyXduO4N3v+oMuGuMBgFK9GzZ798A+BXY45IE8Si2I7x8Yds0Gczc0pHcmG2wmOuR71bPhLNQoX8bspFhRSGdCRDzT32vX/LrscGkh1zbCLhifunHqda+nufNoB84gTvAvo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.5.241] (unknown [10.168.5.241]) (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 4CE2B380BF; Mon, 6 May 2024 09:07:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1714986451; 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=hpRLHTiNAUdKtUm/4yR682Pafx8URZiMe57ftUeu3bM=; b=dm2Png83/ngeJRRbIzZq7jJnAgIPAJ3ZFhwIhre4pWJoule6M4He1W/+HcO/r6XdN0HOvT 9K8bE8t3KjKWLovCZQxadD4PhlaRVVbyPNkNBWguWEVJXjYnATUnZmtc+6W4qX45TdhnYB W5D3URzatzsMXsHfA4WN7fyRu4SRipc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1714986451; 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=hpRLHTiNAUdKtUm/4yR682Pafx8URZiMe57ftUeu3bM=; b=IaWC34Pkew2ctvUZTxMxdjgtHu2iSjuvxqb6E2yiWqjLcmcCaaqZQdHtNRV1s8qAmRgc/8 Q0o5UvHTO9rn1/AQ== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1714986451; 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=hpRLHTiNAUdKtUm/4yR682Pafx8URZiMe57ftUeu3bM=; b=dm2Png83/ngeJRRbIzZq7jJnAgIPAJ3ZFhwIhre4pWJoule6M4He1W/+HcO/r6XdN0HOvT 9K8bE8t3KjKWLovCZQxadD4PhlaRVVbyPNkNBWguWEVJXjYnATUnZmtc+6W4qX45TdhnYB W5D3URzatzsMXsHfA4WN7fyRu4SRipc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1714986451; 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=hpRLHTiNAUdKtUm/4yR682Pafx8URZiMe57ftUeu3bM=; b=IaWC34Pkew2ctvUZTxMxdjgtHu2iSjuvxqb6E2yiWqjLcmcCaaqZQdHtNRV1s8qAmRgc/8 Q0o5UvHTO9rn1/AQ== Date: Mon, 6 May 2024 11:07:31 +0200 (CEST) From: Richard Biener To: Martin Uecker cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types In-Reply-To: <716c2beda1d6f9876612d42902cc8a21c593ed2a.camel@tugraz.at> Message-ID: <747s85p3-3o6r-6913-42p8-8477894p8771@fhfr.qr> References: <05B84303-9D17-4DAE-A9D9-A77DA3EA7878@suse.de> <39fcac8a1c61acaaa1c80602b76f48ef73f5f885.camel@tugraz.at> <3s4pqo5q-qron-7899-p7q4-rpr81n2q0p90@fhfr.qr> <716c2beda1d6f9876612d42902cc8a21c593ed2a.camel@tugraz.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-318882572-1714986451=:2000" X-Spam-Score: -3.30 X-Spam-Level: X-Spamd-Result: default: False [-3.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email] X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-318882572-1714986451=:2000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Mon, 6 May 2024, Martin Uecker wrote: > Am Montag, dem 06.05.2024 um 09:00 +0200 schrieb Richard Biener: > > On Sat, 4 May 2024, Martin Uecker wrote: > > > > > Am Freitag, dem 03.05.2024 um 21:16 +0200 schrieb Jakub Jelinek: > > > > > On Fri, May 03, 2024 at 09:11:20PM +0200, Martin Uecker wrote: > > > > > > > > > TYPE_CANONICAL as used by the middle-end cannot express this but > > > > > > > > > > > > > > Hm. so how does it work now for arrays? > > > > > > > > > > Do you have a testcase which doesn't work correctly with the arrays? > > > > > > I am mostly trying to understand better how this works. But > > > if I am not mistaken, the following example would indeed > > > indicate that we do incorrect aliasing decisions for types > > > derived from arrays: > > > > > > https://godbolt.org/z/rTsE3PhKc > > > > This example is about pointer-to-array types, int (*)[2] and > > int (*)[1] are supposed to be compatible as in receive the same alias > > set.  > > In C, char (*)[2] and char (*)[1] are not compatible. But with > COMPAT set, the example operates^1 with char (*)[] and char (*)[1] > which are compatible. If we form equivalence classes, then > all three types would need to be treated as equivalent. > > ^1 Actually, pointer to functions returning pointers > to arrays. Probably this example can still be simplified... > > > This is ensured by get_alias_set POINTER_TYPE_P handling, > > the alias set is supposed to be the same as that of int *. It seems > > we do restrict the handling a bit, the code does > > > > /* Unnest all pointers and references. > > We also want to make pointer to array/vector equivalent to > > pointer to > > its element (see the reasoning above). Skip all those types, too. > > */ > > for (p = t; POINTER_TYPE_P (p) > > || (TREE_CODE (p) == ARRAY_TYPE > > && (!TYPE_NONALIASED_COMPONENT (p) > > || !COMPLETE_TYPE_P (p) > > || TYPE_STRUCTURAL_EQUALITY_P (p))) > > || TREE_CODE (p) == VECTOR_TYPE; > > p = TREE_TYPE (p)) > > > > where the comment doesn't exactly match the code - but C should > > never have TYPE_NONALIASED_COMPONENT (p). > > > > But maybe I misread the example or it goes wrong elsewhere. > > If I am not confusing myself too much, the example shows that > aliasing analysis treats the the types as incompatible in > both cases, because it does not reload *a with -O2. > > For char (*)[1] and char (*)[2] this would be correct (but an > implementation exploiting this would need to do structural > comparisons and not equivalence classes) but for  > char (*)[2] and char (*)[] it is not. Oh, these are function pointers, so it's about the alias set of a pointer to FUNCTION_TYPE. I don't see any particular code trying to make char[] * (*)() and char[1] *(*)() inter-operate for TBAA iff the FUNCTION_TYPEs themselves are not having the same TYPE_CANONICAL. Can you open a bugreport and please point to the relevant parts of the C standard that tells how pointer-to FUNCTION_TYPE TBAA is supposed to work? Thanks, Richard. > Martin > > > > > > Richard. > > > > > Martin > > > > > > > > > > > > > E.g. same_type_for_tbaa has > > > > > type1 = TYPE_MAIN_VARIANT (type1); > > > > > type2 = TYPE_MAIN_VARIANT (type2); > > > > > > > > > > /* Handle the most common case first. */ > > > > > if (type1 == type2) > > > > > return 1; > > > > > > > > > > /* If we would have to do structural comparison bail out. */ > > > > > if (TYPE_STRUCTURAL_EQUALITY_P (type1) > > > > > || TYPE_STRUCTURAL_EQUALITY_P (type2)) > > > > > return -1; > > > > > > > > > > /* Compare the canonical types. */ > > > > > if (TYPE_CANONICAL (type1) == TYPE_CANONICAL (type2)) > > > > > return 1; > > > > > > > > > > /* ??? Array types are not properly unified in all cases as we have > > > > > spurious changes in the index types for example. Removing this > > > > > causes all sorts of problems with the Fortran frontend. */ > > > > > if (TREE_CODE (type1) == ARRAY_TYPE > > > > > && TREE_CODE (type2) == ARRAY_TYPE) > > > > > return -1; > > > > > ... > > > > > and later compares alias sets and the like. > > > > > So, even if int[] and int[0] have different TYPE_CANONICAL, they > > > > > will be considered maybe the same. Also, guess get_alias_set > > > > > has some ARRAY_TYPE handling... > > > > > > > > > > Anyway, I think we should just go with Richi's patch. > > > > > > > > > > Jakub > > > > > > > > > > > > > > > > > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) --8323328-318882572-1714986451=:2000--