This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Shouldn't convert_scalars_to_vector call free_dominance_info?

On March 10, 2016 6:02:58 PM GMT+01:00, "H.J. Lu" <> wrote:
>On Thu, Mar 10, 2016 at 6:57 AM, H.J. Lu <> wrote:
>> On Thu, Mar 10, 2016 at 5:49 AM, Jakub Jelinek <>
>>> 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,
>>> 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:
>> 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.


>We can call free_dominance_info in convert_scalars_to_vector in
>64-bit or unconditionally.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]