[VP9] ARM / NEON test failures

[GoogleCodeExporter]

v1.3.0-1382-g82d0789

With the above I can reproduce similar failures with the codesourcery 
(arm-2013.05) toolchain.

from:
https://groups.google.com/a/webmproject.org/d/msg/codec-devel/ewquAgd3-fI/DpWVTU
BP0w8J

---

I'm reporting an issue when I run test_libvpx test case on ARMv7 architecture.
It encounter assertion and stop test_libvpx.
But it wouldn't encounter when using --target=generic-gnu (None ARM NEON 
support) 

----------------------------
$ ./test_libvpx --gtest_filter=VP9/DatarateTestVP9.BasicRateTargeting/0
Note: Google Test filter = VP9/DatarateTestVP9.BasicRateTargeting/0
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from VP9/DatarateTestVP9
[ RUN      ] VP9/DatarateTestVP9.BasicRateTargeting/0
test_libvpx: ../libvpx/vp9/encoder/vp9_encodeframe.c:1456: rd_use_partition: 
Assertion `chosen_rate < 2147483647 && chosen_dist < 2147483647' failed.
Aborted
----------------------------

Original issue reported on code.google.com by jz...@chromium.org on 22 Feb 2014 at 12:34

[GoogleCodeExporter]

Original comment by jz...@google.com on 22 Feb 2014 at 12:35

[GoogleCodeExporter]

I duplicated the error,  strangely error only occurs when you do -O1 but not 
when you turn on all the flags individually for -O1:  for instance: 
CFLAGS="-fauto-inc-dec -fcompare-elim -fcprop-registers -fdce -fdefer-pop 
-fdelayed-branch -
fdse -fguess-branch-probability -fif-conversion2 -fif-conversion 
-fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fsplit-wi
de-types -ftree-bit-ccp -ftree-builtin-call-dce -ftree-ccp -ftree-ch 
-ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fo
rwprop -ftree-fre -ftree-phiprop -ftree-sra -ftree-pta -ftree-ter 
-funit-at-a-time -O" ./configure --target=armv7-linux-gcc --disable-optimi
zations

This binary doesn't exhibit the problem.   

Any suggestions?

Original comment by jimbankoski@google.com on 23 Feb 2014 at 6:26

[GoogleCodeExporter]

This works too: 
CFLAGS="-fauto-inc-dec -fcompare-elim -fcprop-registers -fdce -fdefer-pop 
-fdelayed-branch -fdse -fguess-branch-probability -fif-conversion2 
-fif-conversion -fipa-pure-const -fipa-profile -fipa-reference 
-fmerge-constants -fsplit-wide-types -ftree-bit-ccp -ftree-builtin-call-dce 
-ftree-ccp -ftree-ch -ftree-copyrename -ftree-dce -ftree-dominator-opts 
-ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sra -ftree-pta 
-ftree-ter -funit-at-a-time -fthread-jumps -falign-functions  -falign-jumps 
-falign-loops -falign-labels -fcaller-saves -fcrossjumping -fcse-follow-jumps  
-fcse-skip-blocks -fdelete-null-pointer-checks -fdevirtualize 
-fexpensive-optimiza
tions -fgcse  -fgcse-lm -finline-small-functions -findirect-inlining -fipa-sra 
-foptimize-sibling-calls -fpartial-inlining -fpeephole2 -fregmove 
-freorder-blocks  -freorder-functions -frerun-cse-after-loop -fsched-interblock 
 -fsched-spec -fschedule-insns  -fschedule-insns2 -fstrict-aliasing 
-fstrict-overflow -ftree-switch-conversion -ftree-pre -ftree-vrp" ./configure 
--target=armv7-linux-gcc --disable-optimizations

Original comment by jimbankoski@google.com on 23 Feb 2014 at 7:54

[GoogleCodeExporter]

> Any suggestions?

Having one state that is reproducible is enough, luckily it happens at such a 
low optimization level, I don't think you'll gain much tweaking compiler 
settings. Better to strip out code differences between this and generic-gnu -- 
you could try neon flags there minus the neon assembly.

Debugging on hardware might help (android or otherwise) or in the meantime 
printf debugging:
...
chosen_dist: 99362818586995307 none_dist: 2147483647 last_part_dist: 
99362818586995307 split_dist:2147483647
test_libvpx: ../vp9/encoder/vp9_encodeframe.c:1461: rd_use_partition: Assertion 
`chosen_rate < 2147483647 && chosen_dist < 2147483647' failed.

Original comment by jz...@google.com on 24 Feb 2014 at 1:27

[GoogleCodeExporter]

This patch appears to fix it..   Honestly don't know why the compiler was 
optimizing wrong for the code as it was, but this code functionally does 
exactly the same thing and doesn't exhibit the problem. 

https://gerrit.chromium.org/gerrit/#/c/68947/2

Not closed yet

Original comment by jimbankoski@google.com on 25 Feb 2014 at 1:44

• Changed state: Started

[GoogleCodeExporter]

I think the core issue was improper register saving in the NEON code. The below 
commits addressed some of this behavior and moving forward the unit tests have 
a register state check for NEON now.

The test above is passing with: v1.3.0-3468-gf349b07.

"Fix a bug in neon that has not save and restore q4-q7 registers."
https://gerrit.chromium.org/gerrit/#/c/69006/

"Save NEON registers in VP8 NEON functions"
https://gerrit.chromium.org/gerrit/#/c/69916/

Original comment by jz...@google.com on 16 Jul 2014 at 6:46

• Changed state: Fixed