[FFmpeg-devel] [WIP][PATCH] Opus Piramid Vector Quantization Search in x86 SIMD asm

[James Darnley]

On 2017-06-09 13:41, Ivan Kalvachev wrote:
> On 6/9/17, Michael Niedermayer <michael at niedermayer.cc> wrote:
>> seems this breaks build with mingw64, didnt investigate but it
>> fails with these errors:
>>
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> collect2: error: ld returned 1 exit status
>> collect2: error: ld returned 1 exit status
>> make: *** [ffmpeg_g.exe] Error 1
>> make: *** Waiting for unfinished jobs....
>> make: *** [ffprobe_g.exe] Error 1
> 
> 
> const_*_edge is used on only one place is the code.
> Would you check if this patch fixes the issue.
> 
> I expected that the addresses would be pre-calculated
> by n/yasm as one value and indexed
> relative to the section start.
> Instead it seems that each entry is represented with
> its own address and offset from it.
> Since the offset is negative it uses all 64 bits and
> it makes difference if it is truncated to 32 bits.
> 
> Same issue could happen with clang tools.

The problem is with the relative addressing.  You need to load the real
address first before you can offset with another register at runtime. So
something like:

> mov  reg1,  [read_only_const]
> mova mmreg, [reg1 + reg2]