http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098
Uros Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #3 from Uros Bizjak <ubizjak at gmail dot com> 2010-10-22 09:03:01
UTC ---
(In reply to comment #2)
> Well, that's a problem of the target. The pattern that is supposed to match
> is:
>
> (define_insn "<sse>_movu<ssemodesuffix>"
> [(set (match_operand:SSEMODEF2P 0 "nonimmediate_operand" "=x,m")
> (unspec:SSEMODEF2P
> [(match_operand:SSEMODEF2P 1 "nonimmediate_operand" "xm,x")]
> UNSPEC_MOVU))]
> "SSE_VEC_FLOAT_MODE_P (<MODE>mode)
> && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
> ...
> The third alternative would be to fix ix86_expand_special_args_builtin to
> emit the correct patterns from the start.
>
> Whatever is done, it probably also needs to be done for some other patterns.
>
> FWIW the second alternative would look like so:
> Index: config/i386/sse.md
> ===================================================================
> --- config/i386/sse.md (revision 165503)
> +++ config/i386/sse.md (working copy)
> @@ -412,8 +412,7 @@ (define_insn "<sse>_movu<ssemodesuffix>"
> (unspec:SSEMODEF2P
> [(match_operand:SSEMODEF2P 1 "nonimmediate_operand" "xm,x")]
> UNSPEC_MOVU))]
> - "SSE_VEC_FLOAT_MODE_P (<MODE>mode)
> - && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
> + "SSE_VEC_FLOAT_MODE_P (<MODE>mode)"
> "movu<ssemodesuffix>\t{%1, %0|%0, %1}"
> [(set_attr "type" "ssemov")
> (set_attr "movu" "1")
>
> and fixes the bug.
Er, no. This is a move, and all moves have the constraint that you removed.
Probably, we have to handle this via an expander that calls ix86_expand_move,
and this will fix the operands at expansion time.
