[RFA] Factor conversion out of COND_EXPR using match.pd pattern

[Marc Glisse]

On Mon, 29 Jun 2015, Jeff Law wrote:

>> That said - for this kind of patterns testcases that exercise the patterns
>> on GIMPLE would be very appreciated.
> It may be the case that these patterns don't make a lot of sense on gimple 
> and should be restricted to generic, at least with our current 
> infrastructure.
>
> The problem is when we lower from generic to gimple, we end up with branchy 
> code, not straight line code and there's no good way I see to write a 
> match.pd pattern which encompasses flow control.

Andrew was working on a way to generate phiopt code automatically from 
match.pd patterns involving cond_expr, I don't know what the status is.

>>> or maybe use a for loop on comparisons, which would give names to
>>> TREE_OPERAND (@0, *). This should even handle the operand_equal_p
>>> alternative:
>>> 
>>> (cond (cmp:c@0 @1 @2) (convert @1) INTEGER_CST@2)

Hmm, looks like I wrote INTEGER_CST before the second occurence of @2 
instead of the first, so it is probably ignored :-(

>> Yes, that would be my reference.
> But won't this require pointer equivalence?  Are INTEGER_CST nodes fully 
> shared?  What if @1 is something more complex than a _DECL node (remember, 
> we're working with GENERIC).  So something like
> (cond (cmp:c@0 @1 @2) (convert @3) INTEGER_CST@4))
>
> And using operand_equal_p seems more appropriate to me (and is still better 
> than the original (cond @0 ...) and grubbing around inside @0 to look at 
> operands.

I don't understand this comment. When you write @1 twice, genmatch emits a 
call to operand_equal_p to check that they are "the same".

-- 
Marc Glisse