#272: altivec specific code segfaults on ppc when compiled with --enable-pic
-----------------------+----------------------
Reporter: kim | Owner:
Type: defect | Status: open
Priority: normal | Component: avcodec
Version: git-master | Resolution:
Keywords: ppc, PIC | Blocked By:
Blocking: | Reproduced: 1
Analyzed: 0 |
-----------------------+----------------------
Comment (by kim):
>what performance effect does this patch have?
>it could slow things down for cases that dont need the extra code
Depends on what you mean by 'cases that don't need the extra code'. If you
compile without PIC, the patch is not used (#ifdef) so no performance loss
here, and if you compile with -fPIC and a 'recent' gcc nothing works
anyway (gcc 4.2 which triggers the bug was released in 2007). I can also
confirm that ASM + patch remains much faster than using the plain C
version of the function.
By the way, gcc is using the same trick to load global symbol in -fPIC
code nowadays:
{{{
static int GLOBAL[3] = {1, 2, 3};
int f(int x) { return GLOBAL[x]; }
}}}
Compiling with gcc -O0 -S -c foo.c one can see that the address of GLOBAL
is computed as so:
{{{
bcl 20,31,.L2
.L2:
mflr 30
addis 30,30,.LCTOC1-.L2@ha
addi 30,30,.LCTOC1-.L2@l
}}}
where .LCTOC1 is the label marking the begining of the TOC section. This
is exactly what the patch does.
Anyway the movrel macro at issue is always followed by *several* memory
accesses so one extra unconditional jump can hardly impact performances. I
also belive this patch to be backward compatible so the code can still be
compiled with older versions of gcc/as (this is untested though).
What the patch does not handle at the moment is the PPC64 architecture
(I'm not even sure this arch is affected by this bug).
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/272#comment:14>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
