public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* RFC: gimple.[ch] break apart
@ 2013-10-31  5:45 Andrew MacLeod
  2013-10-31  6:15 ` Jeff Law
                   ` (2 more replies)
  0 siblings, 3 replies; 116+ messages in thread
From: Andrew MacLeod @ 2013-10-31  5:45 UTC (permalink / raw)
  To: gcc-patches

Hopefully the other attempts to send this aren't queued up...  in any 
case, maybe I can't even attach a .dot file?... So no attachments this 
time...

instead, the diagram is here:
http://gcc.gnu.org/wiki/rearch?action=AttachFile&do=view&target=gimple.png

-------------------------------------------------------------

I've made 4 attempts now to split gimple.[ch] into reasonable component
parts, and I've finally found something that I can make work and fits my
plans.

I've attached a diagram to (hopefully :-) clarify things.

The original purpose of gimple.[ch] was to provide gimple statements.
This replaces the tcc_statement tree kind during the gimplification
process. No other tree kinds have been converted to gimple
structs/classes.  That what the next stage of my project will do.

As a result, any gimple queries regarding types, decls, or expressions
are actually tree queries. They are sprinkled throughout gimple.[ch] and
gimplify.[ch], not to mention tree.[ch] as well as other parts of the
compiler where they happened to be needed.  This has caused various
ordering issues among the inline functions when I tried to split out the
stmt, iterator, and gimplification bits from gimple.[ch].  Not to
mention a lack of an obvious home for some of these functions.

I'd like to move these as I encounter them into a new file,
gimple-decl.[ch].  When I'm working on the other gimple classes, this
will be further split into gimple-decl, gimple-type and gimple-expr as
appropriate but it seems reasonable to create just the one file now to
clump them since there is no other formal organization. So any function
which is actually querying/setting/building a decl, type, or expression
for gimple would go here.

I also want to split out the structure and accessing bits of the gimple
statement structure into gimple-stmt.[ch].  This would be just the
struct decls as well as all the accessing/setting/building functions...

The gimple_stmt_iterators (gsi) themselves also break out into their own
file quite naturally.

I find that gimple_seq does not seem to be a very clearly defined
thing.  Although a gimple_seq is just a typedef for a gimple stmt (I
thought it use to be a container?), it provides some additional
statement queuing functionality.   Ie, you don't have to worry about
next and prev pointers in the stmt's you build, you simply queue them up
and attach them where you want.  In that sense, its a kind of overlay on
top of a gimple-stmt as it provides additional functionality.
gimple_seq also utilizes gimple_smt_iterators under the covers. They do
not expose the iterators to a function using a gimple_seq but they do
need that knowledge to mange the lists under the covers (thus a dashed
line in the diagram).

Its unclear to me whether gimple_seq's are intended to have a future, or
whether their functionality should be rolled right into statements
themselves.  I believe it may be possible to include gimple-iterator.h
in gimple-stmt.c to provide the implementation without affecting the
inheritance layout, although I haven't actually tried that path.

Or we can treat them as a different layer with their own gimple-seq.[ch]
files.

Or we could combine gimple_seq and gsi routines in the same file, but
that would have the downside of exposing the gsi routines to the
gimplifier, which should have no need of.   Either of the latter 2
options seem reasonable to me for now.

The remnants of gimple.[ch] would contain various general helper
routines (walkers, etc), much like tree-ssa.[ch] does for ssa.

And finally gimplify.[ch] would contain all the stuff required for the
front ends to generate gimple code.  This is actually a front end
interface.  At the moment it isn't obvious since all the current gimple
code also uses trees and calls the gimplifier frequently. As I push
gimple types and decls into the back end and remove trees, the backend
should simply generate gimple directly.  Gimplify should slowly become
usable only via tree based front ends...  (Thus the dotted line from BE
to gimplify.. it should be removed eventually)

Which means that all the front end files should be including *only*
gimplify.h, and getting everything they need from there. Currently a
number of them include gimple.h which should not be required.

How reasonable or unreasonable does this sound? :-)  I've been tearing
the file apart in different ways and orders, and this seems to be the
most workable solution I have come up with that doesn't involve hacks.

Andrew


^ permalink raw reply	[flat|nested] 116+ messages in thread

end of thread, other threads:[~2014-07-29  8:07 UTC | newest]

Thread overview: 116+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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).