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.
