On 17/09/12 16:13, Christophe Lyon wrote: > On 17 September 2012 14:56, Richard Earnshaw <rearn...@arm.com> wrote: >> On 05/09/12 23:14, Christophe Lyon wrote: >>> Hello, >>> >>> Although the recent optimization I have committed to use Neon vext >>> instruction for suitable builtin_shuffle calls does not support >>> big-endian yet, I have written a patch to the existing testcases such >>> they now support big-endian mode. >>> >>> I think it's worth improving these tests since writing the right masks >>> for big-endian (such that the program computes the same results as in >>> little-endian) is not always straightforward. >>> >>> In particular: >>> * I have added some comments in a few tests were it took me a while to >>> find the right mask. >>> * In the case of the test which is executed, I had to force the >>> noinline attribute on the helper functions, otherwise the computed >>> results are wrong in big-endian. It is probably an overkill workaround >>> but it works :-) >>> I am going to file a bugzilla for this problem. >>> >>> I have checked that replacing calls to builtin_shuffle by the expected >>> Neon vext variant produces the expected results in big-endian mode, >>> and I arranged the big-endian masks to get the same results. >>> >>> Christophe.= >>> >>> >>> neon-vext-big-endian-tests.patch >>> >>> >>> N ¬n‡r¥ªíÂ)emçhÂyhi× ¢w^™©Ý >>> >> >> >> I'm not sure about this. Looking at the documentation in the manual for >> builtin_suffle makes no mention of the results/behaviour being endian >> dependent, which makes me wonder why this test needs to be. >> >> R. > > > Indeed, but I had to modify the mask value in order to get the same > results in big and little-endian. > > If the mask should be the same (it would be much more confortable for > the developers indeed), then GCC needs to be changed/fixed. >
That's what I'm trying to establish. I suspect that there is a bug in GCC for all big-endian code here. What happens for a test of uint8x8_t? R. > Christophe. >
