x86: h264: Don't keep data in the redzone across function calls on 64 bit unix

We know that the called function (ff_chroma_inter_body_mmxext)
doesn't touch the redzone, and thus will be kept intact - thus,
this doesn't fix any bug per se.

However, valgrind's memcheck tool intentionally assumes that the
redzone is clobbered on every function call and function return
(see a long comment in valgrind/memcheck/mc_main.c). This avoids
false positives in that tool, at the cost of an extra stack pointer
adjustment.

The other alternative would be a valgrind suppression for this issue,
but that's an extra burden for everybody that wants to run libavcodec
within valgrind.

Signed-off-by: Martin Storsjö <martin@martin.st>
This commit is contained in:
Martin Storsjö 2012-02-20 11:24:35 +02:00
parent 0776e0ef6b
commit 570d4b2186
1 changed files with 5 additions and 5 deletions

View File

@ -821,10 +821,10 @@ cglobal deblock_v_chroma_8, 5,6
; int8_t *tc0) ; int8_t *tc0)
;----------------------------------------------------------------------------- ;-----------------------------------------------------------------------------
cglobal deblock_h_chroma_8, 5,7 cglobal deblock_h_chroma_8, 5,7
%if UNIX64 %if ARCH_X86_64
%define buf0 [rsp-24] ; This could use the red zone on 64 bit unix to avoid the stack pointer
%define buf1 [rsp-16] ; readjustment, but valgrind assumes the red zone is clobbered on
%elif WIN64 ; function calls and returns.
sub rsp, 16 sub rsp, 16
%define buf0 [rsp] %define buf0 [rsp]
%define buf1 [rsp+8] %define buf1 [rsp+8]
@ -840,7 +840,7 @@ cglobal deblock_h_chroma_8, 5,7
movq m0, buf0 movq m0, buf0
movq m3, buf1 movq m3, buf1
TRANSPOSE8x4B_STORE PASS8ROWS(t5, r0, r1, t6) TRANSPOSE8x4B_STORE PASS8ROWS(t5, r0, r1, t6)
%if WIN64 %if ARCH_X86_64
add rsp, 16 add rsp, 16
%endif %endif
RET RET