>From [1]
> > It's not obvious to me why movv16qi requires a nonimmediate_operand
> > source, especially since ix86_expand_vector_mode does have code to
> > cope with constant operand[1]s. emit_move_insn_1 doesn't check the
> > predicates anyway, so the predicate will have little effect.
> >
> > A workaround would be to check legitimate_constant_p instead of the
> > predicate, but I'm not sure that that should be necessary.
> >
> > Has this already been discussed? If not, we should loop in the x86
> > maintainers (but I didn't do that here in case it would be a repeat).
>
> I also noticed it. Not sure why movv16qi requires a
> nonimmediate_operand, while ix86_expand_vector_mode could deal with
> constant op. Looking forward to Hongtao's comments.
The code has been there since 2005 before I'm involved.
It looks to me at the beginning both mov<mode> and
*mov<mode>_internal only support nonimmediate_operand for the
operands[1].
And r0-75606-g5656a184e83983 adjusted the nonimmediate_operand to
nonimmediate_or_sse_const_operand for *mov<mode>_internal, but not for
mov<mode>. I think we can align the predicate between mov<mode>
and *mov<mode>_internal.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/sse.md (mov<mode>): Align predicates for
operands[1] between mov<mode> and *mov<mode>_internal.
---
gcc/config/i386/sse.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index d1010bc5682..7ecfbd55809 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1387,7 +1387,7 @@ (define_mode_attr DOUBLEMASKMODE
(define_expand "mov<mode>"
[(set (match_operand:VMOVE 0 "nonimmediate_operand")
- (match_operand:VMOVE 1 "nonimmediate_operand"))]
+ (match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"))]
"TARGET_SSE"
{
ix86_expand_vector_move (<MODE>mode, operands);
--
2.31.1
