2014-09-30 17:30 GMT+01:00 Jeff Law <l...@redhat.com>: > On 09/30/14 08:37, Jiong Wang wrote: >> >> >> On 30/09/14 05:21, Jeff Law wrote: >>> >>> On 09/29/14 13:24, Jiong Wang wrote: >>>> >>>> I don't think so. from the x86-64 bootstrap, there is no regression >>>> on the number of functions shrink-wrapped. actually speaking, >>>> previously only single mov dest, src handled, so the disallowing >>>> USE/CLOBBER will not disallow shrink-wrap opportunity which was >>>> allowed previously. >>> >>> This is the key, of course. shrink-wrapping is very restrictive in its >>> ability to sink insns. The only forms it'll currently shrink are simple >>> moves. Arithmetic, logicals, etc are left alone. Thus disallowing >>> USE/CLOBBER does not impact the x86 port in any significant way. >> >> >> yes, and we could get +1.22% (2567 compared with 2536) functions >> shrink-wrapped >> after we sinking more insn except simple "mov dest, src" on x86-64 >> bootstrap. and >> I remember the similar percentage on glibc build. >> >> while on aarch64, the overall functions shrink-wrapped increased +25% on >> some >> programs. maybe we could gain the same on other RISC backend. >> >>> >>> I do agree with Richard that it would be useful to see the insns that >>> are incorrectly sunk and the surrounding context. > > So I must be missing something. I thought the shrink-wrapping code wouldn't > sink arithmetic/logical insns like we see with insn 14 and insn 182. I > thought it was limited to reg-reg copies and constant initializations.
yes, it was limited to reg-reg copies, and my previous sink improvement aimed to sink any rtx A: be single_set B: the src operand be any combination of no more than one register and no non-constant objects. while some operator like shift may have side effect. IMHO, all side effects are reflected on RTX, together with this fail_on_clobber_use modification, the rtx returned by single_set_no_clobber_use is safe to sink if it meets the above limit B and pass later register use/def check in move_insn_for_shrink_wrap ? Regards, Jiong > > Jeff > >