On Mon, Jun 29, 2015 at 3:12 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > 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.
I stopped due to many different things. One was match.pd was too immature for conditional expressions. The other reason was because I had other things to do internally. I might pick up but it won't be for another three months. Thanks, Andrew > >>>> 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
