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: "Kirill Yukhin" <kirill dot yukhin at gmail dot com>
- Cc: <gcc at gcc dot gnu dot org>,<ubizjak at gmail dot com>, <hubicka at ucw dot cz>
- Date: Thu, 27 Jun 2019 03:10:32 -0600
- Subject: Re: [PATCH] x86: fix CVT{,T}PD2PI insns
- References: <5D14866E020000780023B753@prv1-mh.provo.novell.com>
>>> 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).
Furthermore there's an issue with Bm and vector_memory_operand:
Whether alignment gets enforced depends on TARGET_AVX. However,
just like the two insns in question here, the SHA ones too don't have
VEX-encoded equivalents, and hence require alignment enforced even
with -mavx. Together with the above I wonder whether Bm shouldn't
be re-purposed to express this special requirement.
Jan