Shouldn't convert_scalars_to_vector call free_dominance_info?

[Jeff Law]

On 03/10/2016 01:18 PM, Richard Biener wrote:
> On March 10, 2016 6:02:58 PM GMT+01:00, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> On Thu, Mar 10, 2016 at 6:57 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Thu, Mar 10, 2016 at 5:49 AM, Jakub Jelinek <jakub@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.
cse can simplify jumps which can invalidate dominance information.

But cse-ing CONST0_RTX and CONSTM1_RTX shouldn't invalidate dominators, 
that's just utter nonsense -- ultimately it has to come down to changing 
jumps.  ISTM HJ has more digging to do here.

jeff