This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] New regressions as of 2003-11-04
- 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>, Daniel Berlin <dberlin at dberlin dot org>, Jan Hubicka <jh at suse dot cz>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Tue, 04 Nov 2003 14:47:26 -0700
- Subject: Re: [tree-ssa] New regressions as of 2003-11-04
- Reply-to: law at redhat dot com
In message <1067981123.14345.66.camel@p4>, Andrew MacLeod writes:
>> Which causes all kinds of headaches :(
>>
>Hrm. Thats bad.
Right.
>So that means threading ought to guarantee that there in no more than
>one jump between the else block and the PHI node tho
Except for a few odd circumstances, yes.
> In that case perhaps remove_useless_stmts_and_vars_cond() needs to know
>that this can happen... it had to be modified (has to be?? :-) to look
>for a single stmt in the target of the COND_EXPR arm now, if that block
>contains nothing but a GOTO and a single stmt in the *next* block, then
>it has the same situation.
I was looking for something a little cleaner than this.
>Unfortunately, I would think thats the right place in this Brave New
>World we have.
Ick.
Alternately, we could try to optimize away PHI nodes of this nature.
ie
BB0
if (set != -1)
goto lab1;
else
goto lab2;
BB1
lab1:
goto lab2;
BB2
lab2:
set = PHI (-1 (BB0), 0 (BB1));
Is the same as:
set = (set != -1) + (-1);
You can generalize that pretty easily to any cases where the PHI alternatives
differ by 1.
Jeff