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 6E7DF384AB58 for ; Sat, 4 May 2024 06:38:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6E7DF384AB58 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 6E7DF384AB58 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=1714804701; cv=none; b=JmzwYStzu+VA+eARrbnueRsMqePzXv9ZA0TBAsGz7PRJMd1bnxbXr5l2gQMUsZumH9mufj1QcSrIRBZaOEK/xt3GRPGTr5667WEdHmsb6gjKVTCSGWtTvKi2gFFGNshzEY1/fL8nm1FD7R5ouojV3Y0Xk8GZyCHEUn6oVChFf7k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714804701; c=relaxed/simple; bh=m9IJJxKBtsD+MviEGalhABfNNwjVN00HgZ1rxUxy2G8=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=Hij5bIapQFlqjykDMI97CwL85KsIQC9vhycAjoA2lwXNPkBjOQsjrumJPsLa/PN3/IyW/1coVMgIS2BgFkk197ezEoiU0OxxwJvkC/ChRaiCWmjD82nzmfvqU/3XH1Yfc3aqxObHJT2n264qx01i5vSmw3Xn10Y726Yy6lvdDUA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.0.221] (84-115-223-216.cable.dynamic.surfer.at [84.115.223.216]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4VWdKM5HBGz1LLF5; Sat, 4 May 2024 08:38:15 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4VWdKM5HBGz1LLF5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1714804696; bh=FoQQGxx52i48CxwUCs1Wer4BjZV76IB8D+QGceQPzNk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=VO7p4N4AY+AMJgCuvRL/z1bRgBNYo1EDIBfN7Cbmokb9pPpABkMENv4biRIwbb+1f hHAd7SCBVzs4h9/Z+UnMz/UqMoqQVMu9wF2ccHZc2XNLIklOk2PT1q9HxMwa4DqHs/ id8qyUSgQT4PRaL4sVfvAuUf+/LOp07AS4QqonRM= Message-ID: Subject: Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types From: Martin Uecker To: Jakub Jelinek Cc: Richard Biener , gcc-patches@gcc.gnu.org Date: Sat, 04 May 2024 08:38:15 +0200 In-Reply-To: References: <05B84303-9D17-4DAE-A9D9-A77DA3EA7878@suse.de> <39fcac8a1c61acaaa1c80602b76f48ef73f5f885.camel@tugraz.at> 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.117 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_ABUSEAT,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 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 bu= t > > > >=20 > > > > Hm. so how does it work now for arrays? > >=20 > > 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 Martin > >=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 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) =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, they > > 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