This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix for mov<mode>_internal pattern

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). 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]