This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Switch stmts and inserting on edges
- From: law at redhat dot com
- To: Jason Merrill <jason at redhat dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>, Andrew Macleod <amacleod at redhat dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Fri, 30 May 2003 15:20:37 -0600
- Subject: Re: [tree-ssa] Switch stmts and inserting on edges
- Reply-to: law at redhat dot com
In message <wvlr86g16kb.fsf@prospero.boston.redhat.com>, Jason Merrill writes:
>On Fri, 30 May 2003 13:25:57 -0600, law@redhat.com wrote:
>
>> In message <wvlvfvs1bwb.fsf@prospero.boston.redhat.com>, Jason Merrill writ
>es:
>> >On 30 May 2003 14:46:47 -0400, Diego Novillo <dnovillo@redhat.com> wrote:
>> >
>> >> On Fri, 2003-05-30 at 11:23, Andrew MacLeod wrote:
>> >>
>> >>> Any other suggestions? I havent thought of anything I actually like...
>.
>> >>>
>> >> The problem is that SWITCH_EXPRs still have implicit semantics that are
>> >> getting in the way. I think this ought to be fixed by finishing Jason'
>s
>> >> patch to expose SWITCH_EXPRs as explicit multi-way branches, or even
>> >> decision trees.
>> >
>> >Agreed.
>
>> Similarly for the backedge in loops.
Well, it's implicit due to having the control structures, but that also
makes things which walk the tree nodes have to know that "special" things
happen that don't show up in the tree nodes, which is painful.
It's also the case that we're going to have to loop discovery anyway, which
is going to provide us with loops constructed with gotos.
>If we need to represent these explicitly, it leads me to wonder again why
>we're retaining the control flow structures at all.
Some of the control flow structure is interesting -- for example BIND_EXPRs
for debugging purposes. Others are much less interesting (such as loops).
jeff