On Thu, Mar 10, 2016 at 12:18 PM, Richard Biener <richard.guent...@gmail.com> wrote: > 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.
It isn't just CONST0_RTX and CONSTM1_RTX. Any instructions changed or generated by the STV pass may be CSEed. > > Can't see how cse can ever invalidate dominators. > CSE may remove statements touched by the 64-bit STV pass. -- H.J.
