This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] COND_EXPR lowering.
- From: law at redhat dot com
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>, Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 24 Oct 2003 11:38:42 -0600
- Subject: Re: [tree-ssa] COND_EXPR lowering.
- Reply-to: law at redhat dot com
In message <1067015177.14175.3041.camel@p4>, Andrew MacLeod writes:
>On Fri, 2003-10-24 at 13:03, Diego Novillo wrote:
>> On Fri, 2003-10-24 at 12:57, Andrew MacLeod wrote:
>> > We dont always use stmt replacement do we?
>> > the insert_on_edge routines update the COND and THEN parts directly, so
>> > it has to be changed there. Perhaps it would be limited to those 2
>> > places, Im not sure.
>> The important thing is: will the statement iterators stop only at
>> COND_EXPR? Or will they also stop at THEN_CLAUSE and ELSE_CLAUSE? If
>> the latter is true, then both THEN_CLAUSE and ELSE_CLAUSE need to have
>> their BB set and we need to keep that in sync with the COND_EXPR.
>> Perhaps we ought to change the semantics of COND_EXPR completely and not
>> consider its clauses separate statements. If we are going to do this,
>> we need to make sure that the iterators never stop at the clauses, only
>> at the parent COND_EXPR.
>Thats what Zdenek saying... they aren't stmts.
And I think that is the core problem. I think the arms ought to be
first class statements.
>And iterators never did look at the clauses... I guess someone iterating
>over everything may have decended into the clauses as part of their
>processing, but thats all part of the patch. Besides, no one does it now
>anyway. Its only an issue when we have the CFG, and then we use block
Yes, we had to explicitly recurse down into the arms. That won't be
necessary anymore since the arms are allowed to have one and only
one form -- a goto.