https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #18 from Thomas Preud'homme <thomas.preudhomme at arm dot com> --- (In reply to Richard Biener from comment #17) > > Citing myself: > > On the GIMPLE level before expansion we have > > +40 = Arr_2_Par_Ref_22(D) + (_41 + pretmp_20); > > _51 = Arr_2_Par_Ref_22(D) + (_41 + (pretmp_20 + 1000)); > > so if _51 were Arr_2_Par_Ref_22(D) + ((_41 + pretmp_20) + 1000); > > then _41 + pretmp_20 would be fully redundant with the expression needed > by _40. Yes I saw that but I was wondering why would reassoc try this association rather than another since the header of the file doesn't mention any special treatment of explicit integer constants. Besides, wouldn't it still misses that fact that _51 = _40 + 1000? > > Note that IIRC one issue with TER is that it is no longer happening as > there are dead stmts around that confuse its has_single_use logic. Thus > placing a dce pass right before expand would fix that and might be a good > idea anyway (see comment #3). Implementing a "proper" poor-mans SSA-based > DCE would be a good way out (out-of-SSA already has one to remove dead > PHIs). Ok
