Skip to content
Snippets Groups Projects
Commit ae53e4b9 authored by Kewen Lin's avatar Kewen Lin Committed by Kewen Lin
Browse files

rs6000: Fix vsx_le_perm_store_* splitters for !reload_completed

For vsx_le_perm_store_* we have two splitters, one is for
!reload_completed and the other is for reload_completed.
As Richard pointed out in [1], operand 1 here is a pure
input for DF and most passes, but it could be used as the
vector rotation (64 bit) destination of itself, so we
re-compute the source (back to the original value) for
the case reload_completed, while for !reload_completed we
generate one new pseudo, so both cases are fine if operand
1 is still live after this insn.  But according to the
source code, for !reload_completed case, it can logically
reuse the operand 1 as the new pseudo generation is
conditional on can_create_pseudo_p, then it can cause
wrong result once operand 1 is live.  So considering this
and there is no splitting for this when reload_in_progress,
this patch is to fix the code to assert can_create_pseudo_p
there, so that both !reload_completed and reload_completed
cases would ensure operand 1 is unchanged (pure input), it
is also prepared for the following up patch which would
strip the unnecessary INOUT constraint modifier "+".

This also fixes an oversight in the splitter for VSX_LE_128
(!reload_completed), it should use operand 1 rather than
operand 0.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660145.html

gcc/ChangeLog:

	* config/rs6000/vsx.md (*vsx_le_perm_store_{<VSX_D:mode>,<VSX_W:mode>,
	v8hi,v16qi,<VSX_LE_128:mode>} !reload_completed splitters): Assert
	can_create_pseudo_p and always generate one new pseudo for operand 1.
parent 118a7241
No related branches found
No related tags found
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment