https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 15 May 2014, thomas.preudhomme at arm dot com wrote: > 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? Yes. But reassoc doesn't associate across POINTER_PLUS_EXPRs. RTL CSE could catch it, but for it the association would have to be the same for both. If we start from the proposed form then at RTL expansion time we could associate pointer + (X + CST) to (pointer + X) + CST. Feels all somewhat hacky, of course (and relies on TER). There may be cases where doing the opposite is better (for example if you have ptr1 + (X + 1000) and ptr2 + (X + 1000)). Association to make CSE possible is always hard if CSE itself cannot associate to maximize the number of CSE opportunities. So at the moment any choice is just canonicalization. > > 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
