https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563
--- Comment #16 from amker at gcc dot gnu.org --- (In reply to Andre Vieira from comment #15) > So the code change for sccp moves the following sequence out of the loop: > > _2 = (sizetype) i_30; > _3 = _2 * 8; > _10 = _3 + 4; > _1 = &a + _10; > a_p = _1; > > This is basically: > *a_p = &a[last_i].y; > > I agree that that makes sense, were it not for the fact that sequence is > recomputing the address of a[i].y which is already computed inside the loop > for: > > MEM[(int *)&a][i_11].y = 100; > > When IVOPTS comes around it creates a code sequence similar to this one to > calculate the address it writes 100 to, and you end up with a needless > recomputation of the address. > > Now I don't know what phase should be responsible for cleaning this up, > whether its sccp's responsibility to realize that the address computation is > the same, or whether there should be some sort of common sub-expression > elimination step in between or something else. Passes have been reordered recently. After that, sink pass runs after lim will sink the computation to loop exit. also there is no pass cleaning it up. Before reordering, assignment to a_p isn't lsm out of loop, there is nothing for sink pass to sink.
