public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Diego Novillo <dnovillo@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: Richard Henderson <rth@redhat.com>, Per Bothner <per@bothner.com>,
	Mark Mitchell <mark@codesourcery.com>,
	gcc@gcc.gnu.org
Subject: Re: Language-independent functions-as-trees representation
Date: Mon, 22 Jul 2002 19:04:00 -0000	[thread overview]
Message-ID: <20020722210212.GA16149@tornado.toronto.redhat.com> (raw)
In-Reply-To: <wvllm86k1m1.fsf@prospero.cambridge.redhat.com>

On Sat, 20 Jul 2002, Jason Merrill wrote:

> I'd like to return to the discussion of a language-independent
> functions-as-trees representation that was going on in January.  At this
> point I'd like to ignore the question of representation within a particular
> frontend (INITIAL?), and focus on what the frontend hands off to the
> middle-end (GENERIC?) and the simplified form which is used in
> optimization (SIMPLE).
> 
I'm curious about GENERIC.  Currently we are making each front
end do an INITIAL->SIMPLE pass via the simplify_function_tree
hook.  What advantage do you see in having INITIAL->GENERIC->SIMPLE?

> Per argues that having (for example) both IF_STMT and COND_EXPR is
> gratuitous duplication.  rth argues that at the SIMPLE level we want to
>
I don't have a strong opinion on this.  All we need is to be able
to do traversals of this kind:

	for every basic block B
	  for every stmt S in B
	    for every expr E in S

whether statements have different codes or are just of type
'void' is the same to me.  But we need to know whether a tree
node affects flow of control or not.  That's important
for building the flowgraph.

> We still need to address the issue of expressing ordering requirements in
> SIMPLE, as discussed in the third thread above.  For instance, currently
>
Nothing was decided.  I think that SEQUENCE_POINT or BARRIER
nodes should be sufficient.  Data dependencies will dictate
natural sequences in the code.  We can then insert barriers when
we need to express partial orderings.  Or maybe, have SEQUENCE
regions (BEGIN_SEQUENCE / END_SEQUENCE).

> In a previous thread, Diego has suggested that inlining would be done on
> language-dependent trees.  I think this is a mistake; IMO it should be done
> at the SIMPLE level.  Requiring the inliner to know about frontend trees is
> wrong.
> 
Ah, yes.  I have changed my mind since then.  One of the
suggestions for doing a Java inliner was to write the
simplification pass for Java and use the existing C inliner.


Diego.

  parent reply	other threads:[~2002-07-22 21:02 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-20 19:47 Jason Merrill
2002-07-20 13:58 ` Per Bothner
2002-07-21 22:04   ` Jason Merrill
2002-07-20 22:17 ` Steven Bosscher
2002-07-21  6:20   ` Richard Henderson
2002-07-21  9:43     ` Steven Bosscher
2002-07-21 14:31       ` Richard Henderson
2002-07-21 15:07         ` Daniel Berlin
2002-07-21 15:15         ` Steven Bosscher
2002-07-21  0:09 ` Neil Booth
2002-07-21  0:41   ` Richard Henderson
2002-07-21  0:13 ` Richard Henderson
2002-07-21  7:06 ` Andreas Jaeger
2002-07-21 11:09   ` Pop Sébastian
2002-07-21 11:44     ` Andreas Jaeger
2002-07-21 23:20       ` Phil Edwards
2002-07-22  2:24         ` Daniel Berlin
2002-07-22  6:23           ` Phil Edwards
2002-07-22  7:10       ` where is tree dump utility Sathiskanna
2002-07-22 13:25         ` Diego Novillo
2002-07-21 17:03 ` Language-independent functions-as-trees representation Mark Mitchell
2002-07-21 20:30   ` Jason Merrill
2002-07-21 22:44     ` Mark Mitchell
2002-07-21 23:06       ` Jason Merrill
2002-07-21 23:53         ` Mark Mitchell
2002-07-22  0:13           ` Jason Merrill
2002-07-22  3:17             ` Daniel Berlin
2002-07-22  5:11     ` Daniel Berlin
2002-07-22  7:18       ` Jason Merrill
2002-07-22 13:11         ` Daniel Berlin
2002-07-23 18:20           ` Jason Merrill
2002-07-27 14:10             ` Pop Sébastian
2002-07-30  9:02               ` Jason Merrill
2002-07-22 21:09   ` Diego Novillo
2002-07-22  2:42 ` where is the data Sathiskanna
2002-07-22 19:04 ` Diego Novillo [this message]
2002-07-23 10:21   ` Language-independent functions-as-trees representation Fergus Henderson
2002-07-23 11:26     ` Diego Novillo
2002-07-23 11:34       ` Toon Moene
2002-07-23 12:01         ` Diego Novillo
2002-07-23 17:48           ` Pop Sébastian
2002-07-26 15:56             ` Jason Merrill
2002-07-23 17:48   ` Jason Merrill
2002-07-23 18:29     ` Andrew Haley
2002-07-23 19:07     ` Richard Henderson
2002-07-23 23:40       ` Jason Merrill
2002-07-24  3:01         ` Richard Henderson
2002-07-24 11:34           ` Jason Merrill
2002-07-23 21:57     ` Fergus Henderson
2002-07-24  0:22       ` Jason Merrill
2002-08-23  5:41 ` Jason Merrill
2002-08-23  6:00   ` Gabriel Dos Reis
2002-08-23  7:41     ` Jason Merrill
2002-08-23  8:22   ` Pop Sébastian
2002-08-23  8:46     ` Jason Merrill
2002-08-23  8:23   ` Jason Merrill
2002-08-23 12:16   ` Diego Novillo
2002-08-23 15:42     ` Daniel Berlin
2002-08-23 17:26     ` Jason Merrill
2002-08-23 17:42       ` Zack Weinberg
2002-08-23 22:25         ` Per Bothner
2002-08-26  0:07           ` Zack Weinberg
2002-08-26  3:07             ` Neil Booth
2002-08-26  3:18               ` Gabriel Dos Reis
2002-08-28  6:50           ` Jason Merrill
2002-08-28 16:42             ` Per Bothner
2002-08-23 22:31       ` Per Bothner
2002-08-26 19:56       ` Diego Novillo
2002-08-29 14:35         ` Richard Henderson
2002-09-03  5:38           ` Jason Merrill
2002-08-26 16:58     ` Paul Brook
2002-08-29 14:21     ` Richard Henderson
2002-08-23 13:01   ` Neil Booth
2002-08-28  4:44     ` Jason Merrill
2002-08-28  5:17       ` Gabriel Dos Reis
2002-08-28  7:10         ` Jason Merrill
2002-08-28  8:02           ` Diego Novillo
2002-08-28  8:32           ` Gabriel Dos Reis
2002-08-28 14:06   ` Jason Merrill
2002-09-10 17:08     ` Gerald Pfeifer
2002-08-29 14:10   ` Richard Henderson
2002-09-03  5:16     ` Jason Merrill
2002-09-04 10:20       ` Paul Brook
2002-08-23 13:53 Robert Dewar
2002-08-23 14:10 ` Neil Booth
2002-08-23 14:14 Robert Dewar
2002-08-23 14:14 ` Neil Booth
2002-08-23 14:35 Robert Dewar
2002-08-23 15:21 ` Neil Booth
2002-08-24  7:59 ` Michael S. Zick
2002-08-23 15:25 Richard Kenner
2002-08-23 15:33 ` Neil Booth
2002-08-23 18:20 Robert Dewar
2002-08-24 12:47 Robert Dewar
2002-08-28  5:03 Robert Dewar

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=20020722210212.GA16149@tornado.toronto.redhat.com \
    --to=dnovillo@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=mark@codesourcery.com \
    --cc=per@bothner.com \
    --cc=rth@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).