On January 15, 2021 8:57:39 PM GMT+01:00, Jakub Jelinek <ja...@redhat.com> wrote: >On Fri, Jan 15, 2021 at 08:48:32PM +0100, Richard Biener wrote: >> On January 15, 2021 7:32:35 PM GMT+01:00, Jakub Jelinek ><ja...@redhat.com> wrote: >> >Hi! >> > >> >On the following testcase, handle_builtin_memcmp in the strlen pass >> >folds >> >the memcmp into comparison of two MEM_REFs. But nothing triggers >> >updating >> >of addressable vars afterwards, so even when the parameters are no >> >longer >> >address taken, we force the parameters to stack and back anyway. >> > >> >The following patch fixes that. >> > >> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >> >> Hmm, we're currently doing it unconditionally at strategic points in >the pass pipeline. Is there no such point after the pass? > >Apparently not. The passes after strlen1 are: >pr96271.c.191t.thread4 >pr96271.c.192t.vrp2 >pr96271.c.193t.copyprop5 >pr96271.c.194t.wrestrict >pr96271.c.195t.dse4 >pr96271.c.196t.cddce3 >pr96271.c.197t.forwprop4 >pr96271.c.198t.phiopt4 >pr96271.c.199t.fab1 >pr96271.c.200t.widening_mul >pr96271.c.201t.store-merging >pr96271.c.202t.tailc >pr96271.c.203t.dce7 >pr96271.c.204t.crited1 >pr96271.c.206t.uncprop1 >pr96271.c.207t.local-pure-const2 >pr96271.c.208t.modref2 >pr96271.c.242t.nrv >pr96271.c.243t.isel >pr96271.c.244t.optimized >and TODO_update_address_taken is used by the inliner, sra, ccp, loop >and >sccvn, so maybe in fre5 in 187.
OK, I think it makes sense to delay until before forwprop4 so can you instead arrange for an unconditional run there? Thanks, Richard. > Jakub
