> 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 the check is (TARGET_AVX && (misaligned_operand(op0) || misaligned_operand(op1)) - in case when TARGET_AVX is false it doesn't matter whether operands are misaligned or not (in this check) - the compiler will always emit movdqa. I understand that this check wasn't used for such cases before and probably isn't intended for that. But in this case, it needs some guarding checks I guess.
On 22 March 2013 20:30, H.J. Lu <hjl.to...@gmail.com> wrote: > On Fri, Mar 22, 2013 at 5:49 AM, Michael Zolotukhin > <michael.v.zolotuk...@gmail.com> 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). There I generated v2di-move with emit_strmov, > > You can't use aligned vector move if alignment is unknown or > not properly aligned. > >> which later used "*movv2di_internal" pattern, and there aligned >> version was chosen because (TARGET_AVX) was false. Probably, that's >> not how emit_strmov should've been used, but then it'd be cool to have >> an assert or an additional check somewhere, which would tell me, that >> I'm using some function in a wrong way. >> So, I guess it's true that in trunk everything is ok here and the >> misaligned case could only come from >> ix86_avx256_split_vector_move_misalign - nevertheless, this place >> seems to me a bit untidy. >> >> > > In ix86_expand_vector_move_misalign, we generate different SSE > unaligned load/store, depending on optimization option. For AVX, > we just use 256-bit unaligned load/store or split it to 128-bit normal > load/store since there is no performance difference between > normal load/store vs unaligned load/store on aligned memory. > > > -- > H.J. -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation.
