On Tue, Apr 9, 2013 at 4:53 PM, Joern Rennecke <joern.renne...@embecosm.com> wrote: > Quoting Richard Biener <richard.guent...@gmail.com>: > > Oops, I missed your final comment when I wrote my first reply. > > >> I fail to see why you need two passes for this rather than considering the >> case that the immediate use stmt of the multiplication we start from >> combines another multiplication with a MINUS_EXPR. That is ... >> >>> + if (use_code == MINUS_EXPR && !negate_p >>> + && gimple_assign_rhs1 (use_stmt) == result >>> + && optab_handler (fms_optab, TYPE_MODE (type)) == >>> CODE_FOR_nothing >>> + && optab_handler (fnma_optab, TYPE_MODE (type)) != >>> CODE_FOR_nothing >>> + && mult_to_fma_pass.second_pass == false) >> >> >> see if that is the case here and simply not do the transform. > > > In other words, I would have to take gimple_assign_rh2 of use_stmt, then > find the statement that sets that value, check if this is a multiply, > and that it is not expanded as a widening multiply (thus duplicating most of > the code in execute_optimize_widening_mul), and also check that if there are > any other uses of the multiply result, that these are likewise reduced to > fma somehow. At which point we hit recursion. This could easily double > the size of this source file. Also, we are alternating between forward > and backward searches, which could lead to quadratic complexity where > we had linear otherwise.
I don't see that. It's merely a complication of optimal handling of a * b +- c * d vs. just a * b +- c. The pass does simple pattern matching only, not doing a global optimal transform, so adding another special-case is reasonable. Special-casing just for single-use 2nd multiplication simplifies the cases for example. Richard. >> A second pass >> will not recover from that without destroying the fnma pattern (testcase?) > > > The second pass is there to generate the fms where we didn't generate fnma. > If fnma (as negate (fma)) has been generated, it will use up the MINUS_EXPR, > so that fms cannot be formed anymore. > This arrangement is a lot simpler than going for a depth-first decision.
