On Mon, 24 Mar 2014 12:49:34 -0000, Martin Storsjö <[email protected]> wrote:
+function ff_mlp_pack_output_inorder_\channels\()ch_mixedshift_armv6, export=1
+ .if SAMPLES_PER_LOOP > 1
+ tst COUNT, #SAMPLES_PER_LOOP - 1 // always seems to be in practice
+ bne X(ff_mlp_pack_output) // but just in case, branch to C
implementation if not
+ .endif
This (and a few similar occurrances further below) is lacking the
"it ne" in order to be able to build it in thumb mode.
Does it fail to build? branch is the only instruction with conditional
encodings in thumb mode. The encodings which require an 'it' only allow
a larger immediate offset.
Yes, it fails to build. Building with apple tools fails simply like this:
libavcodec/arm/mlpdsp_armv6.S:-915:9: error: unsupported relocation on symbol
bne _ff_mlp_pack_output
Building with proper binutils on linux fails at the linking stage:
libavcodec/libavcodec.a(mlpdsp_armv6.o): In function
`ff_mlp_pack_output_inorder_2ch_0shift_armv6':
libavcodec/arm/mlpdsp_armv6.S:353:(.text+0x4): relocation truncated to fit:
R_ARM_THM_JUMP19 against symbol `ff_mlp_pack_output' defined in .text section
in libavcodec/libavcodec.a(mlpdsp.o)
Perhaps it's worth raising this as a fault against the toolchains? At the
time of assembly, the assembler must be aware that it's emitting a branch
to an external symbol, and it's stupid of it to use an encoding that its
native linker is unable to relocate. (Of course in the meantime we can
change libav to be more explicit about the encoding to use.)
For the record, Thumb has 4 different encodings for conditional branches,
which can be written
@ not in an it block
b<cond>.n <target>
it <cond>
b<cond>.n <target>
@ not in an it block
b<cond>.w <target>
it <cond>
b<cond>.w <target>
All four have different ranges (I list them above in increasing range
order, as well as more cycles to execute and lower code density). Is it
only the last one that's safe on all toolchains?
Even the last one only has a range of +/- 16 MB, and given the size of
the libavcodec binary, I'm guessing the linker probably already has to
generate some sort of trampolines to permit branching from any function
to any other in the resulting binary...
Ben
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
