Thanks, On 2021/4/14 14:41, Richard Biener wrote: >> "#538,#235,#234,#233" will all be sunk from bb 35 to bb 37 by rtl-sink, >> but it moves #538 first, then #235, there is strong dependency here. It >> seemsdoesn't like the LCM framework that could solve all and do the >> delete-insert in one iteration. > So my question was whether we want to do both within the LCM store > sinking framework. The LCM dataflow is also used by RTL PRE which > handles both loads and non-loads so in principle it should be able > to handle stores and non-stores for the sinking case (PRE on the > reverse CFG). > > A global dataflow is more powerful than any local ad-hoc method.
My biggest concern is whether the LCM DF framework could support sinking *multiple* reverse-dependent non-store instructions together by *one* calling of LCM DF. If this is not supported, we need run multiple LCM until no new changes, it would be time consuming obviously (unless compiling time is not important here). > > Richard. > >> However, there are still some common methods could be shared, like the >> def-use check(though store-motion is per bb, rtl-sink is per loop), >> insert_store, commit_edge_insertions etc. >> >> >> 508: L508: >> 507: NOTE_INSN_BASIC_BLOCK 34 >> 12: r139:DI=r140:DI >> REG_DEAD r140:DI >> 240: L240: >> 231: NOTE_INSN_BASIC_BLOCK 35 >> 232: r142:DI=zero_extend(r139:DI#0) >> 233: r371:SI=r142:DI#0-0x1 >> 234: r243:DI=zero_extend(r371:SI) >> REG_DEAD r371:SI >> 235: r452:DI=r262:DI+r139:DI >> 538: r194:DI=r452:DI >> 236: r372:CCUNS=cmp(r142:DI#0,r254:DI#0) Like here, Each instruction's dest reg is calculated in the input vector bitmap, after solving the equations by calling pre_edge_rev_lcm, move #538 out of loop for the first call, then move #235 out of loop after a second call... 4 repeat calls needed in total here, is the LCM framework smart enough to move the all 4 instruction within one iteration? I am worried that the input vector bitmap couldn't solve the dependency problem for two back chained instructions. -- Thanks, Xionghu
