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. We can call free_dominance_info in convert_scalars_to_vector in 64-bit or unconditionally. -- H.J.
