Thanks for the hints!
gen_movv2di seems to handle the situation well: it calls
ix86_expand_vector_move which honors alignment and emits correct code.
However, it was very convenient to use gen_strmov for moves in any
mode - I just needed to define the biggest mode with which a piece of
memory could
On Fri, Mar 22, 2013 at 9:58 AM, Michael Zolotukhin
wrote:
>> You can't use aligned vector move if alignment is unknown or
>> not properly aligned.
> Yes, sure. But I just emit V2DI move for an operands, which are
> aligned to 64-bit (not 128-bit!) - and it's encoded into movdqa which
Can you try
> You can't use aligned vector move if alignment is unknown or
> not properly aligned.
Yes, sure. But I just emit V2DI move for an operands, which are
aligned to 64-bit (not 128-bit!) - and it's encoded into movdqa which
is obviously incorrect. The compiler knows, that operands are
misaligned, but
On Fri, Mar 22, 2013 at 5:49 AM, Michael Zolotukhin
wrote:
>> Do you have a testcase to show there is a problem?
>> The misaligned case should only be generated from
>> ix86_avx256_split_vector_move_misalign.
> I faced it when playing with optimized expanding of memmov (with
> vector instructions)
> Do you have a testcase to show there is a problem?
> The misaligned case should only be generated from
> ix86_avx256_split_vector_move_misalign.
I faced it when playing with optimized expanding of memmov (with
vector instructions). There I generated v2di-move with emit_strmov,
which later used "*
On Thu, Mar 21, 2013 at 9:36 AM, Michael Zolotukhin
wrote:
> Hi,
> I've found a little bit strange code in "mov_internal"
> RTL-pattern from config/i386/sse.md:
> case MODE_V2DF:
> if (TARGET_AVX
> && (misaligned_operand (operands[0], mode)
> || misal
Hi,
I've found a little bit strange code in "mov_internal"
RTL-pattern from config/i386/sse.md:
case MODE_V2DF:
if (TARGET_AVX
&& (misaligned_operand (operands[0], mode)
|| misaligned_operand (operands[1], mode)))
return "vmovupd\t{%1, %0|%0
