This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] x86: fix CVT{,T}PD2PI insns
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: <ubizjak at gmail dot com>
- Cc: <gcc at gcc dot gnu dot org>,"Kirill Yukhin" <kirill dot yukhin at gmail dot com>, <hubicka at ucw dot cz>
- Date: Thu, 27 Jun 2019 04:46:56 -0600
- Subject: Re: [PATCH] x86: fix CVT{,T}PD2PI insns
- References: <5D14866E020000780023B753@prv1-mh.provo.novell.com> <5D148808020000780023B75A@prv1-mh.provo.novell.com> <CAFULd4bz65DvEcec_QjsNzxBCWHA9PinE=nk6Jmt4ifJm3VJKA@mail.gmail.com>
>>> On 27.06.19 at 12:22, <ubizjak@gmail.com> wrote:
> On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich <JBeulich@suse.com> wrote:
>>
>> >>> On 27.06.19 at 11:03, wrote:
>> > With just an "m" constraint misaligned memory operands won't be forced
>> > into a register, and hence cause #GP. So far this was guaranteed only
>> > in the case that CVT{,T}PD2DQ were chosen (which looks to be the case on
>> > x86-64 only).
>> >
>> > Instead of switching the second alternative to Bm, use just m on the
>> > first and replace nonimmediate_operand by vector_operand.
>>
>> While doing this and the others where I'm also replacing Bm by uses of
>> vector_operand, I've started wondering whether Bm couldn't (and then
>> shouldn't) be dropped altogether, replacing it everywhere by "m"
>> combined with vector_operand (or vector_memory_operand when
>> register operands aren't allowed anyway).
>
> No. Register allocator will propagate unaligned memory in non-AVX
> case, which is not allowed with vector_operand.
I'm afraid I don't understand: Unaligned SIMD memory accesses will
generally fault in non-AVX mode, so such propagation would seem
wrong to me and hence would seem to be correctly not allowed.
Furthermore both vector_operand and Bm resolve to the same
vector_memory_operand. The TARGET_AVX check actually is inside
vector_memory_operand, i.e. affects both the same way.
Jan