> 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.
gcc/ChangeLog:
* config/i386/sse.md (mov<mode>): Align predicates for
operands[1] between mov<mode> and *mov<mode>_internal.
* config/i386/mmx.md (mov<mode>): Ditto.
(define_expand "mov<mode>"
[(set (match_operand:MMXMODE 0 "nonimmediate_operand")
- (match_operand:MMXMODE 1 "nonimmediate_operand"))]
+ (match_operand:MMXMODE 1 "nonimm_or_0_operand"))]
"TARGET_MMX || TARGET_MMX_WITH_SSE"
{
ix86_expand_vector_move (<MODE>mode, operands);
(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);