>>> On 21.12.18 at 14:55, <ubiz...@gmail.com> wrote:
> On Fri, Dec 21, 2018 at 9:08 AM Jan Beulich <jbeul...@suse.com> wrote:
>>
>> For 64-bit these should not be emitted without suffix in AT&T mode (as
>> being ambiguous that way); the suffixes are benign for 32-bit. For
>> consistency also omit the suffix in Intel mode for {,V}CVTSI2SxQ.
>>
>> The omission has originally (prior to rev 260691) lead to wrong code
>> being generated for the 64-bit unsigned-to-float/double conversions (as
>> gas guesses an L suffix instead of the required Q one when the operand
>> is in memory). In all remaining cases (being changed here) the omission
>> would "just" lead to warnings with future gas versions.
>>
>> Since rex64suffix so far has been used also on {,V}CVTSx2SI (but
>> not on VCVTSx2USI, as gas doesn't permit suffixes there), testsuite
>> adjustments are also necessary for their test cases. Rather than
>> making thinks check for the L suffixes in 32-bit cases, make things
>> symmetric with VCVTSx2USI and drop the redundant suffixes instead,
>> dropping the Q suffix expectations at the same time from the 64-bit
>> cases.
>
> This diverges from established practice, where all instructions have
> suffixes in ATT dialect. I think that we should to continue to follow
> established convention (that found a couple of bugs in the past), so I
> think that "l" should be emitted where appropriate. I wonder if gas
> should be fixed to accept suffixes for VCVTSx2USI.
I did wonder too (a long while ago), but H.J. is strictly objecting to
making things consistent there.
> For now, let's leave all suffixes, but skip problematic VCVTSx2USI.
Hmm, I've checked some older gas versions, and it looks like
they all accept rex64suffix on the 2si conversions, even for 32-bit
code, so I guess retaining rex64suffix there despite the change to
its definition ought to be fine.
>> In order for related test cases to actually test what they're supposed
>> to test, add (seemingly unrelated) a few empty "asm volatile()".
>> Presumably there are more where constant propagation voids the intended
>> effect of the tests, but these are ones helping make sure the assembler
>> actually still assembles correctly the output after the changes here.
>
> Please just make relevant variable volatile. There are plenty of
> examples in the i386 target testsuite.
I've seen that, but considering it bad practice I didn't follow that
model. I've similarly found examples of asm() use as done here,
so I thought both would be okay, and I've picked the variant
being better practice imo. Please clarify if you insist on making
the change. Use of volatile has - iirc - the undesirable side
effect of the compiler emitting VMOV* for the memory accesses,
instead of using the instruction of interest with memory operands
(which, considering the suffix aspect here, is one of the things to
test here).
Jan
