[FFmpeg-devel] [PATCH] intreadwrite: Altivec implementations of AV_COPY128 and AV_ZERO128.

[Reimar Döffinger]

On Sun, Mar 08, 2015 at 10:37:53PM +0100, Michael Niedermayer wrote:
> On Sun, Mar 08, 2015 at 09:59:21PM +0100, Reimar Döffinger wrote:
> > On Sun, Mar 08, 2015 at 08:44:50PM +0100, Michael Niedermayer wrote:
> > > On Sun, Mar 08, 2015 at 07:43:29PM +0100, Reimar Döffinger wrote:
> > > > On 08.03.2015, at 19:34, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > > > On Sun, Mar 08, 2015 at 05:16:43PM +0100, Reimar Döffinger wrote:
> > > > >> Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
> > > > >> in my tests on a G4 7450.
> > > > >> 
> > > > >> Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> > > > > 
> > > > > breaks build:
> > > > > CC      libavcodec/aliaspixdec.o
> > > > > libavcodec/aliaspixdec.c: In function ‘decode_frame’:
> > > > > libavcodec/aliaspixdec.c:35:75: error: expected identifier or ‘(’ before ‘unsigned’
> > > > 
> > > > What compiler/os/... is this? I only tried on Linux, not OSX for example. Though maybe I just messed up the merge, sorry my PPC machine doesn't have email.
> > > 
> > > gcc 4.6 (Debian 4.6.3-14)
> > > 
> > > the problem is the "pixel" identifer, renaming it make it build the
> > > affected file
> > 
> > Hm, I don't have that issue with 4.9.
> > I guess something's broken with the altivec header?
> > Looking at the 4.9 version a #undef pixel right after
> > the altivec.h include might fix it?
> > Assuming we don't actually use it anywhere as an altivec
> > keyword.
> 
> your patch with #undef pixel added after the include:
> 
> CC      libavcodec/dss_sp.o
> libavcodec/dss_sp.c: In function ‘dss_sp_gen_exc’:
> libavcodec/dss_sp.c:473:1: error: parameter name omitted

That seems to be due to the vector define.
I don't think we can avoid that, to my knowledge using __vector
instead doesn't work with some OSX compilers (plus it's kind
of ugly).
It would be possible to undefine them only in intreadwrite.h,
but that would mean altivec code that includes it before
altivec.h will break.
Does anyone have a suggestion on how to solve this that isn't
completely horrible?
I guess a gcc version check might be an option, assuming that's
what makes the difference...