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
> 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.
Jakub
