diff options
author | liuhongt <hongtao.liu@intel.com> | 2024-08-20 14:41:00 +0800 |
---|---|---|
committer | liuhongt <hongtao.liu@intel.com> | 2024-08-21 10:49:57 +0800 |
commit | bb42c551905024ea23095a0eb7b58fdbcfbcaef6 (patch) | |
tree | d127d9cfe0ba986e04597e69ec95553a628d8a6f /libgo/go/net/http/response_test.go | |
parent | 964c9c247ca691e92f046070dd487f0e0e56958e (diff) | |
download | gcc-master.zip gcc-master.tar.gz gcc-master.tar.bz2 |
> 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.
Diffstat (limited to 'libgo/go/net/http/response_test.go')
0 files changed, 0 insertions, 0 deletions