This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] COND_EXPR lowering preview
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 27 Aug 2003 13:52:04 -0600
- Subject: Re: [tree-ssa] COND_EXPR lowering preview
- Reply-to: law at redhat dot com
In message <email@example.com>, Diego Novillo wr
>On Tue, 2003-08-26 at 14:53, Zdenek Dvorak wrote:
>> It disables control structures removal in dce; this also has to be
>> handled separately.
>What does this have to do with COND_EXPR lowering?
A lot actually. If you have lowered COND_EXPRs, then there is very little
value in tracking control dependencies in DCE.
>> It removes linearization from cfg cleanup, since the half of it
>> is redundant with the patch and the rest contains several
>> serious bugs (the most important one being that it uses merge_blocks; this
>> function contains more bugs than correct code :-(
>Test cases? Better yet. Fixes? Generalizations like this one are
As for cfg cleanup, I'd really like to see some analysis on both the
bugs and with/without. ie, I don't want to start taking steps backwards
in terms of performance. Simply claiming its unncessary isn't enough.
Similarly for merge blocks. Analysis please.
>> Some possibly useful cleanups were removed from
>> remove_useless_stmts_and_vars; this function is not suitable for
>> work over unstructured code.
>Again. Please separate this. It has little to do with COND_EXPR
Actually remove_useless_stmts_and_vars is supposed to work with unstructured
code. If it does not, I'd really like to see some analysis why.
>> COND_EXPR lowering is being done in gimplification; if you like/dislike
>> it, cry -- I personally have no opinion whether it should be done there
>> or somewhere later.
>I still think we should separate this from the gimplifier. We should
>probably have a single lowering pass that runs immediately before we
>build the flow graph.
I don't see the value in having it separate. All that does is force
another walk over the statements, which seems awful wasteful. I'd
prefer to see this lowering happen during gimplification.