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

Arun Raghavan arun.raghavan at collabora.co.uk
Sun Dec 18 21:20:11 PST 2011


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



More information about the pulseaudio-discuss mailing list