http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 10 Mar 2014, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 > > --- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > Shouldn't we just prefer the original IL if possible? That is not > SSA_NAME_VERSION, but not gimple_uid of the stmt definition either. > If you have: > _4 = something; > _5 = somethingelse; > _6 = somethingdifferent; > _7 = _6 + _4; > _8 = _7 + _5; > then both SSA_NAME_VERSION and gimple_uid of def_stmt sorting would result in > _9 = _4 + _5; > _8 = _9 + _6; > wouldn't it? But what do we gain by reassociating this (perhaps it can help > value numbering and CSE if you have differently ordered sequences, but other > than that this seems to be unnecessary reshufling and especially for floating > point values and -ffast-math unnecessary source of extra ulps). > So perhaps we want to sort by gimple uid of the first use among the insns we > are looking at (and take into account also the operand number)? Yes, it wants to canonicalize to get more CSE as followup. So sorting after SSA_NAME_VERSION (or its definition UID) does make sense ... Looking at the first use is also possible, but what _is_ the first use? _4 = something if (foo) _5 = _4 + 1; else _6 = _4 + 2;
