Peter, Segher:
On 7/23/24 2:26 PM, Peter Bergner wrote:
On 7/19/24 3:04 PM, Carl Love wrote:
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 5af9bf920a2..2a18ee44526 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -878,9 +878,9 @@ (define_int_attr SLDB_lr [(UNSPEC_SLDB "l")
(define_int_iterator VSHIFT_DBL_LR [UNSPEC_SLDB UNSPEC_SRDB])
(define_insn "vs<SLDB_lr>db_<mode>"
- [(set (match_operand:VI2 0 "register_operand" "=v")
- (unspec:VI2 [(match_operand:VI2 1 "register_operand" "v")
- (match_operand:VI2 2 "register_operand" "v")
+ [(set (match_operand:VEC_IC 0 "register_operand" "=v")
+ (unspec:VEC_IC [(match_operand:VEC_IC 1 "register_operand" "v")
+ (match_operand:VEC_IC 2 "register_operand" "v")
(match_operand:QI 3 "const_0_to_12_operand" "n")]
VSHIFT_DBL_LR))]
"TARGET_POWER10"
I know the old code used the register_operand predicate for the vector
operands, but those really should be changed to altivec_register_operand.
Peter
Segher's response was:
register_operand is just fine usually. The "v" constraint already makes
sure things end up in a VMX (a lower VSX) register, the predicate
doesn't help here. register_operand is shorter (and thus, preferred),
and also more likely correct if the code changes later 🙂
Which Peter said and Segher responded:
On Wed, Jul 24, 2024 at 12:12:05PM -0500, Peter Bergner wrote:
On 7/24/24 12:06 PM, Segher Boessenkool wrote:
I thought we always wanted the predicate to match the constraint being used?
Predicates and constraints have different purposes, and are used at
different times (typically). Everything before RA is predicates
only, and RA and everything after it use constraints (as well).
register_operand says it has to be a register. It allows any
pseudo-register, so before RA, there is no real difference between
register_operand and altivec_register_operand (which allows all pseudos
as well)..
The constraint should not demand things that weren't clear earlier,
because that will then cause reloading eventually, often with less
efficient code. It still will*work* though.
But that is not the case here 🙂
So, I think the final word here is don't change it.
Carl
