[pulseaudio-discuss] [PATCH] svolume_{mmx, sse}, sconv_sse: Fix compilation errors with X32 toolchain

[Arun Raghavan]

On Tue, 2011-12-13 at 09:43 -0800, Kamble, Nitin A wrote:
> > -----Original Message-----
> > From: Arun Raghavan [mailto:arun.raghavan at collabora.co.uk]
> > Sent: Monday, December 12, 2011 8:40 PM
> > To: General PulseAudio Discussion
> > Cc: Kamble, Nitin A
> > Subject: Re: [pulseaudio-discuss] [PATCH] svolume_{mmx, sse},
> > sconv_sse: Fix compilation errors with X32 toolchain
> > 
> > On Sat, 2011-12-10 at 10:03 +0100, Paul Menzel wrote:
> > > From d8b81d5393df36085009bf9f69d41fa85e2ae58a Mon Sep 17 00:00:00
> > 2001
> > > From: Nitin A Kamble <nitin.a.kamble at intel.com>
> > > Date: Sat, 10 Dec 2011 09:09:06 +0100
> > >
> > > Make assembly syntax compatible to the X32 toolchain and fix the
> > > following kind of compilations errors with X32 gcc.
> > >
> > > | pulsecore/svolume_mmx.c: Assembler messages:
> > > | pulsecore/svolume_mmx.c:107: Error: `(%esi,%rdi,4)' is not a valid
> > base/index expression
> > > | pulsecore/svolume_mmx.c:135: Error: `(%esi,%rdi,4)' is not a valid
> > base/index expression
> > > | pulsecore/svolume_mmx.c:161: Error: `(%esi,%rdi,4)' is not a valid
> > base/index expression
> > > | pulsecore/svolume_mmx.c:162: Error: `8(%esi,%rdi,4)' is not a valid
> > base/index expression
> > > | pulsecore/svolume_mmx.c:180: Error: `(%esi,%rdi,4)' is not a valid
> > base/index expression
> > > | pulsecore/svolume_mmx.c:210: Error: `(%esi,%rdi,4)' is not a valid
> > base/index expression
> > > | pulsecore/svolume_mmx.c:244: Error: `(%esi,%rdi,4)' is not a valid
> > base/index expression
> > > | pulsecore/svolume_mmx.c:245: Error: `8(%esi,%rdi,4)' is not a valid
> > base/index expression
> > > | make[3]: *** [libpulsecore_1.1_la-svolume_mmx.lo] Error 1
> > >
> > > Originally these assembly lines were written for x86_64 ABI, now they
> > > are also compatible with X32 ABI [3][4].
> > >
> > > The patch was submitted to the OpenEmbedded-Core list [1][2].
> > >
> > > [1] http://lists.linuxtogo.org/pipermail/openembedded-core/2011-
> > December/014189.html
> > > [2] http://git.yoctoproject.org/cgit.cgi/poky-
> > contrib/commit/?h=nitin/x32&id=2d8eec54f755c51f2eff600390f5a4b3cc2a7662
> > > [3] https://wiki.yoctoproject.org/wiki/X32_abi
> > > [4] http://en.wikipedia.org/wiki/X32_ABI
> > > ---
> > > Please keep Nitin in CC when replying.
> > > ---
> > 
> > I might be missing something, but I've not been able to find any
> > documentation for this syntax (gcc.org docs still show the %<number>
> > use). Could you point me to some documentation?
> > 
> > Also, does this require some version of gcc to work? Not a deal-breaker
> > for me (but might be for others) -- does this work with clang too?
> > 
> > Cheers,
> > Arun
> 
> This syntax is documented in the gcc source code. http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/i386.c?revision=182191&view=markup
> 
> 13495 	/* Print the name of register X to FILE based on its machine mode and number.
> 13496 	If CODE is 'w', pretend the mode is HImode.
> 13497 	If CODE is 'b', pretend the mode is QImode.
> 13498 	If CODE is 'k', pretend the mode is SImode.
> 13499 	If CODE is 'q', pretend the mode is DImode.
> 13500 	If CODE is 'x', pretend the mode is V4SFmode.
> 13501 	If CODE is 't', pretend the mode is V8SFmode.
> 13502 	If CODE is 'h', pretend the reg is the 'high' byte register.
> 13503 	If CODE is 'y', print "st(0)" instead of "st", if the reg is stack op.
> 13504 	If CODE is 'd', duplicate the operand for AVX instruction.
> 13505 	*/

I could at least find this to expand on that a bit --
http://www.delorie.com/gnu/docs/gcc/gccint_53.html -- but I still don't
understand how the DImode is actually interpreted/used.

> This syntax was added when gcc supported x86_64. So older version is not an issue. 
> 
> Clang should support it too, otherwise it is not compatible with gcc, and it will 
> not be able build glibc which as this syntax in it's code.

I've pushed this change out now. Works fine for me on 64-bit, I'm
assuming you've tested at least on x32, and if anyone can report with
some testing on x86 and on multichannel output, would be great.

Cheers,
Arun