On Sat, Mar 03, 2018 at 10:55:28PM -0600, Peter Bergner wrote:
> In PR84264, we hit an assert in rs6000_emit_le_vsx_store causing an ICE
> in LRA. We get there, because LRA called the movv4si expander to generate
> a spill and the mov pattern calls rs6000_emit_le_vsx_move which in turn
> calls rs6000_emit_le_vsx_store. The rs6000_emit_le_vsx_{load,store}
> routines are used at expand time when targeting P8 on an LE system to
> generate vsx load/store insns along with their associated byte swaps.
> After expand, we shouldn't call them, hence the asserts.
>
> The problem in this case is that LRA calls the movv4si expander to
> generate a spill store and we satisfy all the conditions that lead
> to calling rs6000_emit_le_vsx_move(). What is different here, is that
> with GCC 8, we now generate altivec lvx/stvx insns which are LE friendly
> and do not need byte swaps. In this specific case, LRA is generating
> a store to an altivec mem, so we shouldn't call rs6000_emit_le_vsx_move(),
> but rather we should just emit the default RTL from the expander.
>
> The simple fix here is to just verify the memory_operand is not an altivec
> mem operand before calling rs6000_emit_le_vsx_move.
>
> This passed bootstrap and regtesting on powerpc64le-linux with no
> regressions. Ok for trunk?
>
> Peter
>
>
> gcc/
> PR target/84264
> * config/rs6000/vector.md:
The ChangeLog entry needs fixing.
Otherwise I'll defer to powerpc maintainers.
>
> gcc/testsuite/
> PR target/84264
> * g++.dg/pr84264.C: New test.
Jakub
