RFA: Fix tree-optimization/55524

[Joern Rennecke]

Quoting Richard Biener <richard.guenther@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.

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