[dpdk-dev] [PATCH] acl: fix build issue with some arm64 compiler

[Honnappa Nagarahalli]

Reduced the CC list (changing the topic slightly)

> >
> > My understanding is that the generated code for both your patch and my
> > changes above is the same. Above suggested changes will conform to
> > ACLE recommendation.
> 
> Though instructions are different. Effective cycles are same even though First
> dup updates the four positions.
Can you elaborate on how the instructions are different?
I wrote the following code with both the methods:

uint32x4_t u32x4_gather_gcc (uint32_t *p0, uint32_t *p1, uint32_t *p2, uint32_t *p3)
{
     uint32x4_t r = {*p0, *p1, *p2, *p3};

     return r;
}

uint32x4_t u32x4_gather_acle (uint32_t *p0, uint32_t *p1, uint32_t *p2, uint32_t *p3)
{
     uint32x4_t r;

     r = vdupq_n_u32 (* p0);
     r = vsetq_lane_u32 (*p1, r, 1);
     r = vsetq_lane_u32 (*p2, r, 2);
     r = vsetq_lane_u32 (*p3, r, 3);

     return r;
}

The generated code has the same instructions for both (omitted the unwanted parts):

u32x4_gather_gcc:
        ld1r    {v0.4s}, [x0]
        ld1     {v0.s}[1], [x1]
        ld1     {v0.s}[2], [x2]
        ld1     {v0.s}[3], [x3]
        ret

u32x4_gather_acle:
        ld1r    {v0.4s}, [x0]
        ld1     {v0.s}[1], [x1]
        ld1     {v0.s}[2], [x2]
        ld1     {v0.s}[3], [x3]
        ret

The first 'ld1r' updates all the lanes in both the cases.

> To make forward progress send the v2 based on the updated logic  just to
> make ACLE  Spec happy, I don’t see any real reason to do it though 😊
Thanks for the patch, it was important to make forward progress.
But, I think we should carry forward the discussion as I plan to change other parts of DPDK on similar lines. I want to understand why you think there is no real reason. The ACLE recommendation mentions the reasoning.

> 
> http://patches.dpdk.org/patch/54656/
>