From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 925153858D28 for ; Mon, 6 May 2024 11:20:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 925153858D28 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 925153858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714994442; cv=none; b=Qkg+kXwy5yyKE/STWphoT08ioo4IiXeYVZC8UHqVP3GMpAll9dJEHoduU+vBbYASzsqBaDvQBqwCQ0ewW8A3RrYZYlEi/5C+XmMixgGzCJyTNUdiNwufP9RAIAvz+qjsreHmiO/nvec0T4C7FdAKtQXgssLwwRxM041sHz4uH1g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714994442; c=relaxed/simple; bh=A7HtQia0FnfyJkyh7XfdN2KYPu3LtFONikjMjyHBCvA=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=mRE18unhnn0hgTskcZuelyFIEp+cK2clmuXOIZCK0WHQTgWpECgaJV0LbI/ee63dH7Qa/4G1Ko6A21mR91F5jLJrUK0G2Crw98IlCK87bpBw2lfAMxYhP2vlbf3mwncgYa791IRG3gOW3YV53mnlLJ4OV4PgnlXZvJ2msqbSTfM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from tug-swl-f124.tugraz.at (tug-swl-f124.tugraz.at [129.27.237.124]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4VXzVD31Ntz1LM0D; Mon, 6 May 2024 13:20:36 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4VXzVD31Ntz1LM0D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1714994436; bh=RBVcv/1UnUit+E3E317/ztDjOFZw/7GpAbcI6/kk4t8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=ebve3lboN5aGY9gZ6y+4e65hMgjZYAV5yqeuFR2QeOxuGVQtue+oeUJpr30GtGAiT MsqNZZfHR3S/grqBo8OtBvfELDUVyn4EDj3u0CRlelvWYtPKgn2lK35zMfJzjOnila WeYNQ7El/KE3zq+lg4Z3OZvQxL9gDt+k0sUopF+0= Message-ID: <3ea18459a1a1cb968919cf270d71dcd441b08311.camel@tugraz.at> Subject: Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types From: Martin Uecker To: Richard Biener Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, Jan Hubicka Date: Mon, 06 May 2024 13:20:36 +0200 In-Reply-To: <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> <747s85p3-3o6r-6913-42p8-8477894p8771@fhfr.qr> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: Am Montag, dem 06.05.2024 um 11:07 +0200 schrieb Richard Biener: > On Mon, 6 May 2024, Martin Uecker wrote: >=20 > > Am Montag, dem 06.05.2024 um 09:00 +0200 schrieb Richard Biener: > > > On Sat, 4 May 2024, Martin Uecker wrote: > > >=20 > > > > 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 > > > > > > > >=20 > > > > > > > > Hm. so how does it work now for arrays? > > > > > >=20 > > > > > > Do you have a testcase which doesn't work correctly with the ar= rays? > > > >=20 > > > > 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: > > > >=20 > > > > https://godbolt.org/z/rTsE3PhKc > > >=20 > > > 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.=C2=A0 > >=20 > > 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.=20 > >=20 > > ^1 Actually, pointer to functions returning pointers > > to arrays. Probably this example can still be simplified... > >=20 > > > 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 > > >=20 > > > /* Unnest all pointers and references. > > > We also want to make pointer to array/vector equivalent to= =20 > > > pointer to > > > its element (see the reasoning above). Skip all those types,= too. =20 > > > */ > > > for (p =3D t; POINTER_TYPE_P (p) > > > || (TREE_CODE (p) =3D=3D ARRAY_TYPE > > > && (!TYPE_NONALIASED_COMPONENT (p) > > > || !COMPLETE_TYPE_P (p) > > > || TYPE_STRUCTURAL_EQUALITY_P (p))) > > > || TREE_CODE (p) =3D=3D VECTOR_TYPE; > > > p =3D TREE_TYPE (p)) > > >=20 > > > where the comment doesn't exactly match the code - but C should > > > never have TYPE_NONALIASED_COMPONENT (p). > > >=20 > > > But maybe I misread the example or it goes wrong elsewhere. > >=20 > > 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.=20 > >=20 > > 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=C2=A0 > > char (*)[2] and char (*)[] it is not. >=20 > 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. >=20 > 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? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114959 Martin >=20 > Thanks, > Richard. >=20 > > Martin > >=20 > >=20 > > >=20 > > > Richard. > > >=20 > > > > Martin > > > >=20 > > > > > >=20 > > > > > > E.g. same_type_for_tbaa has > > > > > > type1 =3D TYPE_MAIN_VARIANT (type1); > > > > > > type2 =3D TYPE_MAIN_VARIANT (type2); > > > > > >=20 > > > > > > /* Handle the most common case first. */ > > > > > > if (type1 =3D=3D type2) > > > > > > return 1; > > > > > >=20 > > > > > > /* If we would have to do structural comparison bail out. */ > > > > > > if (TYPE_STRUCTURAL_EQUALITY_P (type1) > > > > > > || TYPE_STRUCTURAL_EQUALITY_P (type2)) > > > > > > return -1; > > > > > >=20 > > > > > > /* Compare the canonical types. */ > > > > > > if (TYPE_CANONICAL (type1) =3D=3D TYPE_CANONICAL (type2)) > > > > > > return 1; > > > > > >=20 > > > > > > /* ??? Array types are not properly unified in all cases as w= e have > > > > > > spurious changes in the index types for example. Removing= this > > > > > > causes all sorts of problems with the Fortran frontend. *= / > > > > > > if (TREE_CODE (type1) =3D=3D ARRAY_TYPE > > > > > > && TREE_CODE (type2) =3D=3D ARRAY_TYPE) > > > > > > return -1; > > > > > > ... > > > > > > and later compares alias sets and the like. > > > > > > So, even if int[] and int[0] have different TYPE_CANONICAL, the= y > > > > > > will be considered maybe the same. Also, guess get_alias_set > > > > > > has some ARRAY_TYPE handling... > > > > > >=20 > > > > > > Anyway, I think we should just go with Richi's patch. > > > > > >=20 > > > > > > Jakub > > > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 >=20