On Wed, 5 Nov 2014, Andrew Pinski wrote: > Hi, > I was trying to hook up tree-ssa-phiopt to match-and-simplify using > either gimple_build (or rather using gimple_simplify depending on if > we want to produce cond_expr for conditional move). I ran into a > problem. > With the pattern below: > /* a ? 0 : 1 -> a if 0 and 1 are integral types. */ > (simplify > (cond_expr @0 integer_zerop integer_onep) > (if (INTEGRAL_TYPE_P (type)) > (convert @0)))
Ok, so you are capturing a GENERIC expr here but nothing knows that. It would work if you'd do (ugh) (for op (lt le eq ne ge gt) (simplify (cond_expr (op @0 @1) integer_zerop integer_onep) (if (INTEGRAL_TYPE_P (type)) (convert (op @0 @1))))) (simplify (cond_expr SSA_NAME@0 integer_zerop integer_onep) (if (INTEGRAL_TYPE_P (type)) (convert @0)))) as a workaround. To make your version work will require (quite) some special-casing in the code generator or maybe the resimplify helper. Let me see if I can cook up a "simple" fix. Richard. > This produces a gimple statement with an incorrect gimple statement > where we have have a convert with an compare expression. > > t.c: In function âfâ: > t.c:1:5: error: invalid operand in unary operation > int f(int c, int a, int b) > ^ > _4 = (int) (c_2(D) != 0); > > > Did I implement the pattern incorrectly or is there a bug due to the > way cond_expr handles its 0th operand in that it is valid for compares > there in gimple form. > > I don't have a good patch to test tree-ssa-phiopt.c connection due the > patch having extra code in it already which handles creating cond_expr > for conditional moves already. > > Thanks, > Andrew Pinski > > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 21284 (AG Nuernberg) Maxfeldstrasse 5, 90409 Nuernberg, Germany
