https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #11 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to Richard Biener from comment #6) > I think > > a - ((b * -c) + (d * -e)) -> a + (b * c) + (d * e) > > is a good simplification to be made, but it's difficult to do this with > canonicalization only. Like a * -b -> -(a * b) as the negate might > combine with both other negates down and upstream. But for > a*-b + c * -d it might be more obvious to turn that into > -a*b - c*d. Yeah, my expectation was that this would be an easier transform to avoid the sharing problem we discussed before and that indeed the transform looks at the entire chain not just transforming a * -b. a*-b + c * -d -> -a*b - c*d has the property of still maintaining the FMS and FMNS chains and can get further simplified in the above case. > > Maybe reassoc can be of help here - IIRC it turns b * -c into > b * c * -1, undistribute_ops_list might get that. hmm I see, but don't we have a higher chance that folding will just fold it back into the multiply? For this to work we'd have to do (b * -c) + (d * -e) -> -(b * c + d * e) in one transformation no? since I'd imagine (b * c * -1) + (d * e * -1) would just be undone by match.pd? > > Note one issue is that complex lowering leaves around dead stmts, > confusing reassoc and forwprop, in particular > > - _10 = COMPLEX_EXPR <_18, _6>; > > stay around until reassoc. scheduling dce for testing shows reassoc > does something. > > It's update_complex_assignment who replaces existing complex > stmts with COMPLEX_EXPRs, we should possibly resort do > simple_dce_from_worklist > to clean those. Let me try to do that. Thanks!
