From: Michael Matz <matz@suse.de>
To: David Malcolm <dmalcolm@redhat.com>
Cc: Andrew MacLeod <amacleod@redhat.com>, Jeff Law <law@redhat.com>,
gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Add gimple subclasses for every gimple code (was Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3))
Date: Thu, 07 Nov 2013 14:57:00 -0000 [thread overview]
Message-ID: <alpine.LNX.2.00.1311071512110.11100@wotan.suse.de> (raw)
In-Reply-To: <1383800204.31927.33.camel@surprise>
Hi,
On Wed, 6 Nov 2013, David Malcolm wrote:
> > I don't like that. The empty classes are just useless, they imply a
> > structure that isn't really there, some of the separate gimple codes
> > are basically selectors of specific subtypes of a generic concept,
> > without additional data or methods; creating a type for those is
> > confusing.
>
> A type system does more than just express memory layouts:
I know all that. But there's a point on the scale from a void* type
system to a different-type-for-everything system where the advantages of a
more complex type system are anulled by the disadvantages of a more
complex type system. And I'm merely of the opinion that you crossed that
point with this separation.
You know we could have a typesystem where every different natural number
is a type (and with C++ we _really_ could do that). Obviously that's also
a reductio ad absurdum, but it demonstrates the point that there _are_
type systems with a too low complexity to expressiveness ratio.
> * it permits the proof of absence of certain bugs
> * it supports abstraction
> * it documents the intent of the code
Well, yes. You can document code with other things than types, you can
add abstractions via different means, and certain bugs can indeed only be
ruled out by different static types.
In my mind types should abstract different larger concepts foremost (and
not every little aspect of a concept). Only _then_ should they be used
for other effects like the above, and only if the disadvantages don't
overshadow that. Disadvantages being mostly simply more complexity: which
types relate to others in which way; what are the methods you can do with
that but not the other type; which are the members of the 100 types there
are (and if a type system is too large to be used only by IDEs with code
completion, then it's too complex); and of course also simply having to
write more text when you can't use the same gimple variable for several
statements.
> To give an example from the patch, the proposed gimple_statement_switch
> subclass of gimple_statement_with_ops adds no extra fields, but it adds
> the invariant that (assuming the ptr is non-NULL), that code ==
> GIMPLE_SWITCH, or, more intuitively, "it's a switch statement".
>
> This means that if we have a gimple_statement_switch, that both a human
> reading the code and the compiler can "know" at compile-time that the
> code == GIMPLE_SWITCH.
But a gimple switch is actually a special case of a gimple conditional
jump (the normal GIMPLE_COND being another) which itself is a special
case of a gimple control transfer (a thing causing one or multiple
outgoing edges and ending a basic block). That enlightens that your
hierarchy might not actually be the best split of types, it's merely a
formal translation of gimple codes into types.
And I question exactly that automatic introduction of types. There's not
enough human thought put into the hierarchy to warrant the change. Types
are a fundament and they shouldn't be introduced lightly. As gimple codes
are simply flat it doesn't matter so much that the inherent structure of
gimple statements isn't reflected (although there _is_ some structure by
having the with_ops and with_mem_ops codes be together). But for a _type
hierarchy_ I would pretty much require that real thought and insights are
put into it.
> Consider tree-switch-conversion.c: this contains various "gimple"
> variables but they don't work on arbitrary gimple; they require code ==
> GIMPLE_SWITCH:
> ...
> We could be doing this directly in the type system, and using the
> compiler to check it.
Then please do that while introducing one new type.
> > The fewer
> > types the better IMO.
>
> There's a reductio ad absurdum of that argument:
See above for my variant of that showing that it also goes into the other
direction of more types.
Ciao,
Michael.
P.S.: And do away with the "_statement" part of the type, gimple_switch
ought to be enough.
next prev parent reply other threads:[~2013-11-07 14:44 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 5:45 RFC: gimple.[ch] break apart Andrew MacLeod
2013-10-31 6:15 ` Jeff Law
2013-10-31 16:41 ` [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3) David Malcolm
2013-10-31 16:27 ` [PATCH 1/6] Convert gimple types from a union to C++ inheritance David Malcolm
2013-11-14 23:00 ` Jeff Law
2013-11-19 0:22 ` David Malcolm
2013-11-19 8:49 ` Jeff Law
2013-10-31 16:27 ` [PATCH 4/6] Implement is_a_helper <>::test specializations for various gimple types David Malcolm
2013-11-14 9:41 ` Jeff Law
2013-11-18 19:51 ` David Malcolm
2013-11-18 20:10 ` Andrew MacLeod
2013-11-18 20:15 ` Jeff Law
2013-10-31 16:27 ` [PATCH 2/6] Hand-written port of various accessors within gimple.h David Malcolm
2013-11-14 9:53 ` Jeff Law
2013-10-31 16:31 ` [PATCH 3/6] Automated part of conversion of gimple types to use C++ inheritance David Malcolm
2013-11-14 9:43 ` Jeff Law
2013-11-18 22:17 ` [PATCH] Updated automated patch (was Re: [PATCH 3/6] Automated part of conversion of gimple types to use C++ inheritance) David Malcolm
2013-11-19 8:49 ` Jeff Law
2013-11-19 16:36 ` David Malcolm
2013-11-22 0:27 ` Jakub Jelinek
2013-11-22 0:35 ` Jeff Law
2013-11-22 1:51 ` Jakub Jelinek
2013-11-22 2:52 ` Andrew MacLeod
2013-11-22 3:48 ` David Malcolm
2013-11-25 18:09 ` [PATCH] Fix checking of gimple types David Malcolm
2013-11-25 18:42 ` Michael Matz
2013-11-25 22:18 ` Jeff Law
2013-11-27 8:54 ` David Malcolm
2014-07-23 13:16 ` Thomas Schwinge
2014-07-24 1:50 ` David Malcolm
2014-07-29 8:11 ` Thomas Schwinge
2013-10-31 16:46 ` [PATCH 6/6] Update gdb hooks to reflect changes to " David Malcolm
2013-11-14 9:10 ` Jeff Law
2013-10-31 16:49 ` [PATCH 5/6] Port various places from union access to subclass access David Malcolm
2013-11-14 9:23 ` Jeff Law
2013-11-19 0:52 ` David Malcolm
2013-10-31 18:43 ` [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3) Basile Starynkevitch
2013-11-01 21:36 ` Andrew MacLeod
2013-11-01 21:41 ` Jakub Jelinek
2013-11-01 21:47 ` Andrew MacLeod
2013-11-01 21:57 ` Jakub Jelinek
2013-11-01 22:58 ` David Malcolm
2013-11-04 13:23 ` Andrew MacLeod
2013-11-04 21:52 ` David Malcolm
2013-11-04 22:09 ` David Malcolm
2013-11-04 22:31 ` Andrew MacLeod
2013-11-05 21:27 ` Jeff Law
2013-11-04 22:43 ` Andrew MacLeod
2013-11-04 22:28 ` Jakub Jelinek
2013-11-04 22:49 ` Andrew MacLeod
2013-11-05 21:09 ` Jeff Law
2013-11-05 11:53 ` Richard Biener
2013-11-05 12:33 ` David Malcolm
2013-11-05 12:52 ` Richard Biener
2013-11-04 14:00 ` Andrew MacLeod
2013-11-04 14:01 ` Jakub Jelinek
2013-11-04 14:15 ` Andrew MacLeod
2013-11-04 18:23 ` Jeff Law
2013-11-01 22:43 ` David Malcolm
2013-11-01 23:43 ` Trevor Saunders
2013-11-04 13:15 ` Andrew MacLeod
2013-11-05 17:23 ` [PATCH] Add gimple subclasses for every gimple code (was Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)) David Malcolm
2013-11-06 16:53 ` Michael Matz
2013-11-07 6:19 ` David Malcolm
2013-11-07 7:08 ` Jeff Law
2013-11-08 19:23 ` David Malcolm
2013-11-14 8:38 ` Jeff Law
2013-11-14 15:06 ` Michael Matz
2013-11-14 18:32 ` David Malcolm
2013-11-15 2:49 ` Jeff Law
2013-11-07 14:57 ` Michael Matz [this message]
2013-11-08 0:07 ` Alec Teal
2013-11-08 14:31 ` Michael Matz
2013-11-05 18:22 ` [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3) Andrew MacLeod
2013-11-05 21:33 ` Jeff Law
2013-11-05 22:01 ` David Malcolm
2013-11-05 22:17 ` Jeff Law
2013-11-06 1:14 ` Ian Lance Taylor
2013-11-06 20:49 ` Jeff Law
2013-11-06 20:57 ` Trevor Saunders
2013-11-05 22:24 ` Andrew MacLeod
2013-11-05 22:12 ` Andrew MacLeod
2013-11-06 9:37 ` Richard Biener
2013-11-06 11:20 ` Bernd Schmidt
2013-11-06 11:43 ` Richard Biener
2013-11-06 11:53 ` Jakub Jelinek
2013-11-06 13:14 ` Richard Biener
2013-11-06 13:23 ` Jakub Jelinek
2013-11-06 16:42 ` David Malcolm
2013-11-06 16:55 ` Jakub Jelinek
2013-11-06 18:34 ` Tom Tromey
2013-11-06 19:15 ` Jeff Law
2013-11-06 20:05 ` Tom Tromey
2013-11-06 20:45 ` Jeff Law
2013-11-06 13:31 ` Joseph S. Myers
2013-11-06 21:25 ` Jeff Law
2013-11-06 21:09 ` Jeff Law
2013-11-06 12:42 ` Bernd Schmidt
2013-11-06 21:04 ` Jeff Law
2013-11-06 21:06 ` Andrew MacLeod
2013-11-06 21:52 ` Jeff Law
2013-11-07 10:29 ` Richard Biener
2013-11-07 14:01 ` Joseph S. Myers
2013-11-07 14:42 ` Richard Biener
2013-11-07 14:53 ` Andrew MacLeod
2013-11-10 12:35 ` Richard Sandiford
2013-11-10 15:27 ` Richard Biener
2013-11-06 11:56 ` Eric Botcazou
2013-11-06 20:51 ` Jeff Law
2013-11-06 21:26 ` Jeff Law
2013-11-14 8:40 ` Jeff Law
2013-11-05 16:58 ` [patch] Create gimple-expr..[ch] ... was Re: RFC: gimple.[ch] break apart Andrew MacLeod
2013-11-05 17:52 ` Jeff Law
2013-11-07 10:58 ` Basile Starynkevitch
2013-11-07 13:47 ` Andrew MacLeod
2013-11-07 18:13 ` Diego Novillo
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=alpine.LNX.2.00.1311071512110.11100@wotan.suse.de \
--to=matz@suse.de \
--cc=amacleod@redhat.com \
--cc=dmalcolm@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=law@redhat.com \
/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).