From: Jason Merrill <jason@redhat.com>
To: Diego Novillo <dnovillo@redhat.com>
Cc: Richard Henderson <rth@redhat.com>, Per Bothner <per@bothner.com>,
Mark Mitchell <mark@codesourcery.com>,
gcc@gcc.gnu.org, Jason Merrill <jason@redhat.com>
Subject: Re: Language-independent functions-as-trees representation
Date: Tue, 23 Jul 2002 17:48:00 -0000 [thread overview]
Message-ID: <wvlptxecra6.fsf@prospero.cambridge.redhat.com> (raw)
In-Reply-To: <20020722210212.GA16149@tornado.toronto.redhat.com> (Diego Novillo's message of "Mon, 22 Jul 2002 17:02:12 -0400")
>>>>> "Diego" == Diego Novillo <dnovillo@redhat.com> writes:
> 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?
Modularity, mainly. The idea is that by the time we get to the
simplification stage there won't be any language-specific trees to worry
about.
On the other hand, going from INITIAL to GENERIC will use a lot of the same
functionality as from GENERIC to SIMPLE, so perhaps it would be simpler
just to go straight to SIMPLE, using a langhook to handle language-specific
trees.
Any other opinions?
>> 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.
Well, anything that can trap affects flow of control; in C++, most function
calls have edges to the local exception handler. In Java, some arithmetic
does as well.
On the other side, a COMPOUND_STMT doesn't affect flow of control; it's
just a way of grouping things at the same level.
I suppose to me, the distinction is not about any intrinsic property of the
statement, it's whether or not its value is used in further calculations.
In expand_expr terms, whether or not "ignore" is true.
>> 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).
I think we also need something to express the absence of ordering
restrictions. If we write f(g(), h()), there will be a sequence point
after each of the calls to g and h (at least in C++). Or if they're
inlined, within the calls. We need to make it explicit that despite the
presence of sequence points, the optimizer can switch the two around.
That's why I was suggesting something like UNORDERED_LIST.
Jason
next prev parent reply other threads:[~2002-07-23 17:06 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 ` Language-independent functions-as-trees representation Diego Novillo
2002-07-23 10:21 ` 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 [this message]
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=wvlptxecra6.fsf@prospero.cambridge.redhat.com \
--to=jason@redhat.com \
--cc=dnovillo@redhat.com \
--cc=gcc@gcc.gnu.org \
--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).