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
