This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Shouldn't convert_scalars_to_vector call free_dominance_info?
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, "Enkovich, Ilya" <ilya dot enkovich at intel dot com>, Uros Bizjak <ubizjak at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 10 Mar 2016 12:25:15 -0800
- Subject: Re: Shouldn't convert_scalars_to_vector call free_dominance_info?
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOqOcS1rTpvJ1n_g2qiWoyPBbNnGZ-R8A1rwqTBheDHpEg at mail dot gmail dot com> <CAFiYyc3HN6Q7OAihgkU7G6i+NdokMGk_qY3jhDnBBym+sJ7SdA at mail dot gmail dot com> <CAMe9rOpOnPH9Fe4k_XfgAfdWvHiGpeMxm4dbnY2VBG7q7_=EDw at mail dot gmail dot com> <CAFiYyc17WXx94Cj=bbo9Cvjw5NaSxAxw5LViysgv4oDMt=QZRg at mail dot gmail dot com> <CAMe9rOpRiGJpYo_rsP0BmCajyjRnYcFNZK_9S3WSLRxfPKKnXA at mail dot gmail dot com> <CAMe9rOr21CUD5pi--PPPcyPu5fydOfL9V+RCk7_sZJU8j6sKcg at mail dot gmail dot com> <20160310134928 dot GV3017 at tucnak dot redhat dot com> <CAMe9rOourtrcZqRdrbRYDVvEy_Msc+CDRnRxuGvbsAkkjF5_eA at mail dot gmail dot com> <CAMe9rOpPCsXx+r6eg_MikehcHsDaS1uhVTrJiAgQJkpkpdjsSg at mail dot gmail dot com> <C56340A9-1040-42A7-9648-961D582B2519 at gmail dot com>
On Thu, Mar 10, 2016 at 12:18 PM, Richard Biener
<richard.guenther@gmail.com> 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.
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.