On March 10, 2016 6:02:58 PM GMT+01:00, "H.J. Lu" <hjl.to...@gmail.com> wrote: >On Thu, Mar 10, 2016 at 6:57 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Thu, Mar 10, 2016 at 5:49 AM, Jakub Jelinek <ja...@redhat.com> >wrote: >>> On Thu, Mar 10, 2016 at 05:43:27AM -0800, H.J. Lu wrote: >>>> > free_dominance_info (CDI_DOMINATORS); >>>> >>>> Since convert_scalars_to_vector may add instructions, dominance >>>> info is no longer up to date. >>> >>> Adding instructions doesn't change anything on the dominance info, >just >>> cfg manipulations that don't keep the dominators updated. >>> You can try to verify the dominance info at the end of the stv pass, >> >> I added >> >> verify_dominators (CDI_DOMINATORS); >> ' >> It did trigger assert in my 64-bit STV pass in 64-bit libgcc build: >> >> /export/gnu/import/git/sources/gcc/libgcc/config/libbid/bid128_fma.c: >> In function \u2018add_and_round.constprop\u2019: >> >/export/gnu/import/git/sources/gcc/libgcc/config/libbid/bid128_fma.c:629:1: >> error: dominator of 158 should be 107, not 101 >> >> I will investigate. > >Here is the problem: > >1. I extended the STV pass to 64-bit to convert TI load/store to >V1TI load/store to use SSE load/store for 128-bit load/store. >2. The 64-bit STV pass generates settings of CONST0_RTX and >CONSTM1_RTX to store 128-bit 0 and -1. >3. I placed the 64-bit STV pass before the CSE pass so that >CONST0_RTX and CONSTM1_RTX generated by the STV pass >can be CSEed. >4. After settings of CONST0_RTX and CONSTM1_RTX are CSEed, >dominance info will be wrong.
Can't see how cse can ever invalidate dominators. Richard. >We can call free_dominance_info in convert_scalars_to_vector in >64-bit or unconditionally.
