[PATCH] COND_EXPRs in GIMPLE code and vectorizer

[Roberto COSTA]

Roberto COSTA wrote:
> Diego Novillo wrote:
> 
>> Roberto COSTA wrote on 09/28/06 05:51:
>>
>>
>>> If time allows me, I'd like to try to see what happens if COND_EXPRs 
>>> are kept throughout the GIMPLE passes (I confess I'm curious). 
>>> Logically, I see them as richer constructs (they carry more 
>>> information than the equivalent control-flow code), like MIN_EXPRs 
>>> and MAX_EXPRs.
>>>
>>
>> Be wary of VRP and thread jumping if you do this.  Both rely on the
>> current COND_EXPR format quite heavily.
> 
> 
> Before committing into anything, I will study the implications on these 
> in order to evaluate the effort needed.

I've recently spent some time to study how vrp, dom and jump threading 
work; such implications are now clear to me.
I don't know yet how to solve them in the hypothesis that as many 
COND_EXPRs as possible are kept throughout the GIMPLE passes.

In the meantime, there are a few changes I made to some of the 
middle-end passes that I think are useful even when the gimplifier 
expands COND_EXPR expressions (the current behavior).
Basically, such passes currently handle COND_EXPR nodes only as 
statements and they may miss optimization opportunities in the presence 
of COND_EXPR expressions.
The following patch extends them to support COND_EXPR expressions.

I succesfully bootstrapped all languages on my i686 machine, with no 
regressions.

Comments?

Cheers,
Roberto
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gcc_cond_patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20061017/5f03edb2/attachment.ksh>