This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH, rs6000] Fix PR84264: ICE in rs6000_emit_le_vsx_store


Hi Peter,

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?

Yes this looks correct, okay for trunk.  Thanks.  But it is very
non-obvious; maybe a comment will help, or the code can be restructured
a bit?


Segher


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