On Fri, Jan 4, 2019 at 9:28 AM Jan Beulich <jbeul...@suse.com> wrote:
>
> >>> 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).
Well, I don't want to bikeshed too much here, my only intention was to
prevent the introduction of yet another approach. If you think that
asm is better here, I'm also OK with your choice, especially since the
proposed approach is also already in widespread use in the testsuite.
Uros.
