This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix for mov<mode>_internal pattern
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Michael Zolotukhin <michael dot v dot zolotukhin at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Uros Bizjak <ubizjak at gmail dot com>
- Date: Fri, 22 Mar 2013 09:30:31 -0700
- Subject: Re: [PATCH] Fix for mov<mode>_internal pattern
- References: <CANtU07-kZrSBt8_nd2Uw4rhQp_iMmH4p8HkYNR=8wtaaRfCXKg at mail dot gmail dot com> <CAMe9rOocMYTD6dM7P99C-m9EFPP6eu4KDMwNm8KXsrdv50dXUA at mail dot gmail dot com> <CANtU079VFL7wesXnSvsbShwiBSQg0F97c0SWW8Ftm4zmxCFccA at mail dot gmail dot com>
On Fri, Mar 22, 2013 at 5:49 AM, Michael Zolotukhin
>> Do you have a testcase to show there is a problem?
>> The misaligned case should only be generated from
> 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.