2014-12-19 3:51 GMT+00:00 Bin.Cheng <amker.ch...@gmail.com>: > On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool > <seg...@kernel.crashing.org> wrote: >> On Thu, Dec 18, 2014 at 05:00:01PM +0000, Jiong Wang wrote: >>> On 17/12/14 15:54, Richard Biener wrote: >>> >ick. I realize we don't have SSA form on RTL but doesn't DF provide >>> >at least some help in looking up definition statements for pseudos? >>> >In fact we want to restrict the transform to single-use pseudos, thus >>> >hopefully it can at least tell us that... (maybe not and this is what >>> >LOG_LINKS are for in combine...?) At least loop-invariant alreadly >>> >computes df_chain with DF_UD_CHAIN which seems exactly what >>> >is needed (apart from maybe getting at single-use info). >>> >>> thanks very much for these inspiring questions. >>> >>> yes, we want to restrict the transformation on single-use pseudo only, >>> and it's better the transformation could re-use existed info and helper >>> function to avoid increase compile time. but I haven't found anything I >>> can reuse at the stage the transformation happen. >>> >>> the info similar as LOG_LINKS is what I want, but maybe simpler. I'd study >>> the code about build LOG_LINKS, and try to see if we can do some factor out. >> >> LOG_LINKs in combine are just historical. combine should be converted >> to use DF fully. >> >> LOG_LINKs have nothing to do with single use; they point from the _first_ >> use to its corresponding def. >> >> You might want to look at what fwprop does instead. > Pass rtl fwprop uses df information in single-definition way, it > doesn't really take into consideration if register is a single use. > This often corrupts other optimizations like post-increment and > load/store pair. For example: > > add r2, r1, r0 > ldr rx, [r2] > add r2, r2, #4 > is transformed into below form: > add r2, r1, r0 > ldr rx, [r1, r0] > add r2, r2, #4 > > As a result, post-increment opportunity is corrupted, also definition > of r2 can't be deleted because it's not single use. > > Thanks, > bin
thanks for all these suggestion. Have look at the LOG_LINK build function, a simple reverse scan, while needs to allocate big map array for all pseudo regs. Haven't looked at similar code in fwprop, actually, when found the first matched insn pattern, I just want to scan several insns next, then abort quickly if nothing meet requirement. there is no need to build full single-use information. still can anyone confirm that it is safe to re-use REG_DEAD info there without calling df_note_add_problem and df_analysis first? or I am using those info passed down from the previous pass which calculated these info and maybe broken?
