On Thu, 15 Apr 2021, Xionghu Luo wrote: > 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).
As said it is used for PRE and there it most definitely can do that. > > > > > 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. > > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
