On Sat, 8 Mar 2014, Janne Grunau wrote:

The overread avoidance fix in cbddee1cca0ebd01e8c5aa694d31228eb4de4b41
broke the computation for the last row since it prevented the safe
reading from the height+1-th row.
---
I'm not fully sure how I came to the conclusion that those values are
not used during the last iteration. I either checked the wrong function
or I just looked above, saw that they are used and incorrectly assumed
that they are already loaded for the next iteration.

My testing was unfortunately flawed since CPUFLAGS=-neon doesn't masks
neon out and I tested on a CPU with neon.

libavcodec/arm/hpeldsp_armv6.S | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/libavcodec/arm/hpeldsp_armv6.S b/libavcodec/arm/hpeldsp_armv6.S
index 984e0f0..f1abc32 100644
--- a/libavcodec/arm/hpeldsp_armv6.S
+++ b/libavcodec/arm/hpeldsp_armv6.S
@@ -132,12 +132,11 @@ function ff_put_pixels8_y2_armv6, export=1
        uhadd8          r9,  r5,  r7
        eor             r11, r5,  r7
        and             r10, r10, r12
-        ldrc_pre        ne,  r4,  r1,  r2
+        ldr_pre         r4,  r1,  r2
        uadd8           r8,  r8,  r10
        and             r11, r11, r12
        uadd8           r9,  r9,  r11
-        it              ne
-        ldrne           r5,  [r1, #4]
+        ldr             r5,  [r1, #4]
        uhadd8          r10, r4,  r6
        eor             r6,  r4,  r6
        uhadd8          r11, r5,  r7
@@ -194,10 +193,9 @@ function ff_put_pixels8_y2_no_rnd_armv6, export=1
1:
        subs            r3,  r3,  #2
        uhadd8          r8,  r4,  r6
-        ldrc_pre        ne,  r4,  r1,  r2
+        ldr_pre         r4,  r1,  r2
        uhadd8          r9,  r5,  r7
-        it              ne
-        ldrne           r5,  [r1, #4]
+        ldr             r5,  [r1, #4]
        uhadd8          r12, r4,  r6
        ldrc_pre        ne,  r6,  r1,  r2
        uhadd8          r14, r5,  r7
--
1.9.0

Ok

// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to