On Mon, May 30, 2016 at 1:15 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Mon, May 30, 2016 at 12:55:22PM +0200, Richard Biener wrote: >> CCing Jakub who wrote the tree-ssa-math-opts.c code last year. I remember we >> discussed using match.pd but ended up with not doing it there but I >> don't remember >> the exact reason. > > <jakub> richi: does match.pd support turning non-call code into internal call? > <richi> jakub: yes > <richi> jakub: (simplify (plus @1 @2) (fn @1 @2)) > <jakub> richi: where fn is IFN_... or something else? > <richi> jakub: IFN_ should work, yes > <richi> jakub: CFN_ as well as far as I understand the code richard added > <jakub> but then I don't control the type of the lhs, right? > <jakub> want to transform > <jakub> r_4 = x_2(D) - y_3(D); > <jakub> if (x_2(D) < r_4) > <jakub> into: > <richi> well, the lhs is always the original type of the expression > (obviously) > <jakub> _4 = SUB_OVERFLOW (x_2(D), y_3(D)); > <jakub> r.0_5 = REALPART_EXPR <_4>; > <jakub> _7 = IMAGPART_EXPR <_4>; > <jakub> if (_7 != 0) > <jakub> unsigned only > <richi> jakub: hmm, you have two results, the compare and the subtract, > that's not possible to handle right now (unless r_4 is unused otherwise) > <richi> jakub: you can write a matcher and do the transform in a pass > somewhere > <jakub> richi: ah, ok; any suggestion which pass is best for this? forwprop, > something else? > <richi> jakub: I'd say forwprop is good enough, yes > <jakub> richi: FYI, this is for PR67089, rth is working on the optab side for > that > <richi> hmm, the (match ...) code doesn't deal well with values not having an > SSA name (the compare in this case) > <richi> "deal well" as in, not implemented > <richi> it would require to output some auxiliary entry points > <jakub> richi: if it is done in forwprop or some other pass, it can do > everything in there by hand, doesn't need match.pd help I guess > <richi> jakub: yes
Ok, so Alexander - you transform the condition only as the multiplication value is not available anyway with your formulation of the overflow check. That's then different to Jakubs case, so match.pd is ok (that is, the patch is ok for trunk). >> It would be nice to have these in one place rather >> than split. >> >> As of umulv<mode>4 handling - users can write overflow checks using the >> builtins >> so we better expand them to the optimal form for each target, thus >> canonicalizing >> them to the IFN looks reasonable to me. > >> The plus/minus case in tree-ssa-math-opts.c >> _does_ disable itself if no uaddv is available though. > > That is because the uaddv/usubv case is so simple without the HW support that > it is unlikely to be beneficial then. That is not the case for > multiplication. Richard. > Jakub
