On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich <jbeul...@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.
Uros.
> 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
>
>
