Re: [PATCH, middle-end]: Fix PR 88070, ICE in create_pre_exit, at mode-switching.c:438

[Uros Bizjak]

On Wed, Nov 21, 2018 at 10:48 AM Uros Bizjak <ubiz...@gmail.com> wrote:
>
> On Wed, Nov 21, 2018 at 12:46 AM Jeff Law <l...@redhat.com> wrote:
> >
> > On 11/19/18 12:58 PM, Uros Bizjak wrote:
> > > Hello!
> > >
> > > The assert in create_pre_exit at mode-switching.c expects return copy
> > > pair with nothing in between. However, the compiler starts mode
> > > switching pass with the following sequence:
> > >
> > > (insn 19 18 16 2 (set (reg:V2SF 21 xmm0)
> > >         (mem/c:V2SF (plus:DI (reg/f:DI 7 sp)
> > >                 (const_int -72 [0xffffffffffffffb8])) [0  S8 A64]))
> > > "pr88070.c":8 1157 {*movv2sf_internal}
> > >      (nil))
> > > (insn 16 19 20 2 (set (reg:V2SF 0 ax [orig:91 <retval> ] [91])
> > >         (reg:V2SF 0 ax [89])) "pr88070.c":8 1157 {*movv2sf_internal}
> > >      (nil))
> > > (insn 20 16 21 2 (unspec_volatile [
> > >             (const_int 0 [0])
> > >         ] UNSPECV_BLOCKAGE) "pr88070.c":8 710 {blockage}
> > >      (nil))
> > > (insn 21 20 23 2 (use (reg:V2SF 21 xmm0)) "pr88070.c":8 -1
> > >      (nil))
> > So I know there's an updated patch.  But I thought it might be worth
> > mentioning that insn 16 here appears to be a nop-move.   Removing it
> > might address this instance of the problem, but I doubt it's general
> > enough to address any larger issues.
> >
> > You still might want to investigate why it's still in the IL.
>
> Oh yes, I remember this.
>
> These nop-moves were removed in Vlad's patch [1],[2]:
>
> 2013-10-25  Vladimir Makarov <vmaka...@redhat.com>
>
>         ...
>         * lra-spills.c (lra_final_code_change): Remove useless move insns.
>
> Which regressed vzeroupper insertion pass [3] that was reported in [4].
>
> The functionality was later reverted in [5]:
>
> 2013-10-26  Vladimir Makarov  <vmaka...@redhat.com>
>
>     Revert:
>     2013-10-25  Vladimir Makarov  <vmaka...@redhat.com>
>     * lra-spills.c (lra_final_code_change): Remove useless move insns.
>
> Which IMO can be reintroduced back, now that vzeroupper pass works in
> a different way. We actually have a couple of tests in place for
> PR58679 [6].

The revert of the revert works OK for PR58679 tests with the latest compiler.

Uros.