Hi,
This patch is to teach rs6000_legitimate_address_p to
handle the queried rtx constructed for LEN_{LOAD,STORE},
since lxvl and stxvl doesn't support x-form or ds-form,
so consider it as not legitimate when outer code is PLUS.
This can help to fix SPEC2017 503.bwaves_r degradation
as reported in PR110248 (note that with explicit option
--param=vect-partial-vector-usage=2), also +1.69% for
507.cactuBSSN_r, +2.35% for 510.parest_r (likely noise),
the others are neutral.
I didn't associate one test case for this as I think
checking some dumping of ivopts or final assembly insns
seems quite fragile.
Bootstrapped and regtested on powerpc64-linux-gnu
P7/P8/P9 and powerpc64le-linux-gnu P9/P10.
Is it ok for trunk?
BR,
Kewen
------
PR tree-optimization/110248
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_legitimate_address_p): Check if
the given code is for ifn LEN_{LOAD,STORE}, if yes then make it not
legitimate when outer code is PLUS.
---
gcc/config/rs6000/rs6000.cc | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index efc54528b23..f5c9289fda0 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -9856,7 +9856,7 @@ use_toc_relative_ref (rtx sym, machine_mode mode)
during assembly output. */
static bool
rs6000_legitimate_address_p (machine_mode mode, rtx x, bool reg_ok_strict,
- code_helper = ERROR_MARK)
+ code_helper ch = ERROR_MARK)
{
bool reg_offset_p = reg_offset_addressing_ok_p (mode);
bool quad_offset_p = mode_supports_dq_form (mode);
@@ -9864,6 +9864,12 @@ rs6000_legitimate_address_p (machine_mode mode, rtx x,
bool reg_ok_strict,
if (TARGET_ELF && RS6000_SYMBOL_REF_TLS_P (x))
return 0;
+ /* lxvl and stxvl doesn't support any addressing modes with PLUS. */
+ if (ch.is_internal_fn ()
+ && (ch == IFN_LEN_LOAD || ch == IFN_LEN_STORE)
+ && GET_CODE (x) == PLUS)
+ return 0;
+
/* Handle unaligned altivec lvx/stvx type addresses. */
if (VECTOR_MEM_ALTIVEC_OR_VSX_P (mode)
&& GET_CODE (x) == AND
--
2.39.3
