On 12 June 2012 10:22, Julian Brown <jul...@codesourcery.com> wrote:
> On Mon, 11 Jun 2012 16:46:27 +0100
> Ramana Radhakrishnan <ramana.radhakrish...@linaro.org> wrote:
>
>> Hi,
>>
>> I don't like the ML bits of the patch as it stands today and before
>> committing I would like to clean up the ML bits quite a bit further
>> especially in areas where I've put FIXMEs [...]
>
> I had a go at this, see attached. Untested. Note there are some
> semantic differences in output:
>
> vzipq_p8 (poly8x16_t __a, poly8x16_t __b)
> {
> poly8x16x2_t __rv;
> - uint8x16_t __mask1 = {0, 2};
> - uint8x16_t __mask2 = {1, 3};
> - __rv.val[0] = (poly8x16_t)__builtin_shuffle (__a, __b, __mask1);
> - __rv.val[1] = (poly8x16_t)__builtin_shuffle (__a, __b, __mask2);
> + uint8x16_t __mask1 = { 0, 16, 1, 17, 2, 18, 3, 19, 4, 20, 5, 21, 6,
> 22, 7, 23 };
> + uint8x16_t __mask2 = { 8, 24, 9, 25, 10, 26, 11, 27, 12, 28, 13, 29,
> 14, 30, 15, 31 };
> + __rv.val[0] = (poly8x16_t) __builtin_shuffle (__a, __b, __mask1);
> + __rv.val[1] = (poly8x16_t) __builtin_shuffle (__a, __b, __mask2);
> return __rv;
> }
>
> I wasn't quite sure which version was correct -- but your version
> doesn't seem to have enough elements for these cases?
>
That's definitely a wart in my implementation. Yes and I wouldn't have
spotted that until I'd fixed up the O0 regressions to see it in the
test run. Thanks for looking over my feeble attempts at ML - I'll have
a look at this post lunch.
regards,
Ramana
> HTH,
>
> Julian
