From: Martin Uecker <uecker@tugraz.at>
To: Richard Biener <rguenther@suse.de>
Cc: Jakub Jelinek <jakub@redhat.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] middle-end/114931 - type_hash_canon and structual equality types
Date: Fri, 03 May 2024 21:11:20 +0200 [thread overview]
Message-ID: <39fcac8a1c61acaaa1c80602b76f48ef73f5f885.camel@tugraz.at> (raw)
In-Reply-To: <05B84303-9D17-4DAE-A9D9-A77DA3EA7878@suse.de>
Am Freitag, dem 03.05.2024 um 20:48 +0200 schrieb Richard Biener:
>
> > Am 03.05.2024 um 20:37 schrieb Martin Uecker <uecker@tugraz.at>:
> >
> > Am Freitag, dem 03.05.2024 um 20:18 +0200 schrieb Jakub Jelinek:
> > > > On Fri, May 03, 2024 at 08:04:18PM +0200, Martin Uecker wrote:
> > > > A change that is not optimal but would avoid a lot of trouble is to
> > > > only use the tag of the struct for computing a TYPE_CANONICAL, which
> > > > could then be set already for incomplete types and never needs to
> > > > change again. We would not differentiate between different struct
> > > > types with the same tag for aliasing analysis, but in most cases
> > > > I would expect different structs to have a different tag.
> > >
> > > Having incompatible types have the same TYPE_CANONICAL would lead to wrong
> > > code IMHO, while for aliasing purposes that might be conservative (though
> > > not sure, the alias set computation is based on what types the element have
> > > etc., so if the alias set is computed for say struct S { int s; }; and
> > > then the same alias set used for struct S { long long a; double b; union {
> > > short c; float d; } c; };, I think nothing good will come out of that),
> >
> > The C type systems requires us to form equivalence classes though.
> > For example
> >
> > int (*r)[1];
> > int (*q)[];
> > int (*p)[3];
> >
> > need to be in the same equivalence class even though r and p are
> > not compatible, while at the same time r and q and q and p
> > are compatible.
>
> TYPE_CANONICAL as used by the middle-end cannot express this but
Hm. so how does it work now for arrays?
> useless_type_conversion_p is directed and has similar behavior.
> Note the dual-use for TBAA and compatibility was convenient but
> maybe we have to separate both since making the equivalence class
> for TBAA larger is more conservative while for compatibility it’s
> the other way around…
Maybe, although I do not understand why the middle end would
need precise knowledge for checking type compatibility? The
FE has much stricter rules.
Martin
>
> Richard
>
> >
> > > but middle-end also uses TYPE_CANONICAL to see if types are the same,
> > > say e.g. useless_type_conversion_p says that conversions from one
> > > RECORD_TYPE to a different RECORD_TYPE are useless if they have the
> > > same TYPE_CANONICAL.
> > > /* For aggregates we rely on TYPE_CANONICAL exclusively and require
> > > explicit conversions for types involving to be structurally
> > > compared types. */
> > > else if (AGGREGATE_TYPE_P (inner_type)
> > > && TREE_CODE (inner_type) == TREE_CODE (outer_type))
> > > return TYPE_CANONICAL (inner_type)
> > > && TYPE_CANONICAL (inner_type) == TYPE_CANONICAL (outer_type);
> > > So, if you have struct S { int s; } and struct S { short a, b; }; and
> > > VIEW_CONVERT_EXPR between them, that VIEW_CONVERT_EXPR will be removed
> > > as useless, etc.
> >
> > Maybe we could limit for purposes of computing TYPE_CANONICAL of derived
> > types, e.g. TYPE_CANONICAL of structs stays the same with the transition
> > from TYPE_STRUCT_EQUALITY to TYPE_CANONICAL but all the derived types
> > remain stable.
> >
> > Martin
> >
> > >
> > > BTW, the idea of lazily updating TYPE_CANONICAL is basically what I've
> > > described as the option to update all the derived types where it would
> > > pretty much do that for all TYPE_STRUCTURAL_EQUALITY_P types in the
> > > hash table (see if they are derived from the type in question and recompute
> > > the TYPE_CANONICAL after recomputing all the TYPE_CANONICAL of its base
> > > types), except perhaps even more costly (if the trigger would be some
> > > build_array_type/build_function_type/... function is called and found
> > > a cached TYPE_STRUCTURAL_EQUALITY_P type). Note also that
> > > TYPE_STRUCTURAL_EQUALITY_P isn't the case just for the C23 types which
> > > are marked that way when incomplete and later completed, but by various
> > > other cases for types which will be permanently like that, so doing
> > > expensive checks each time some build*_type* is called that refers
> > > to those would be expensive.
> > >
> > > Jakub
> > >
> >
next prev parent reply other threads:[~2024-05-03 19:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 12:13 Richard Biener
2024-05-03 15:32 ` Martin Uecker
2024-05-03 16:23 ` Richard Biener
2024-05-03 17:44 ` Martin Uecker
2024-05-03 17:30 ` Jakub Jelinek
2024-05-03 18:04 ` Martin Uecker
2024-05-03 18:18 ` Jakub Jelinek
2024-05-03 18:37 ` Martin Uecker
2024-05-03 18:48 ` Richard Biener
2024-05-03 19:11 ` Martin Uecker [this message]
2024-05-03 19:16 ` Jakub Jelinek
2024-05-04 6:38 ` Martin Uecker
2024-05-06 7:00 ` Richard Biener
2024-05-06 7:27 ` Martin Uecker
2024-05-06 9:07 ` Richard Biener
2024-05-06 11:20 ` Martin Uecker
2024-05-07 11:05 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39fcac8a1c61acaaa1c80602b76f48ef73f5f885.camel@tugraz.at \
--to=uecker@tugraz.at \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).