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

> 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 <> wrote:
> 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.
> --
> H.J.

Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.

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