[llvm-bugs] [Bug 46105] New: ARM NEON vld3_u8 incorrect optimization

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46105

            Bug ID: 46105
           Summary: ARM NEON vld3_u8 incorrect optimization
           Product: clang
           Version: 10.0
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: guilder13 at yandex-team.ru
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

Not sure if it's shortest snippet, but it's much less than original.

#include "arm_neon.h"

typedef unsigned char uint8;
typedef unsigned short uint16;
typedef short int16;

inline void decompressColor(const uint8 color_RGB444[3], uint8 color[3])
{
  color[0] = (color_RGB444[0] << (8 - 4)) | (color_RGB444[0] >> (4 - (8-4)) );
  color[1] = (color_RGB444[1] << (8 - 4)) | (color_RGB444[1] >> (4 - (8-4)) );
  color[2] = (color_RGB444[2] << (8 - 4)) | (color_RGB444[2] >> (4 - (8-4)) );
}

#pragma clang optimize off
uint8x8_t noopt(uint8x8_t possible_colors_v[4][3], uint8x8x3_t rgba_u8[2])
{
  // fake usage
}
#pragma clang optimize on

int calculateError59T_NEON(const uint8* srcimg, uint8 (colorsRGB444)[2][3],
uint8 &distance, unsigned int &pixel_indices,
                           int best_block_error = 65535)
{
  // Problem line
  uint8x8x3_t rgba_u8[2] = { vld3_u8(srcimg), vld3_u8(srcimg + 3 * 8) };

  uint8 color0[3];
  uint8 color1[3];
  decompressColor(colorsRGB444[0], color0);
  decompressColor(colorsRGB444[1], color1);
  uint8x8_t possible_colors_v[4][3];
  possible_colors_v[0][0] = vdup_n_u8(color0[0]);
  possible_colors_v[0][1] = vdup_n_u8(color0[1]);
  possible_colors_v[0][2] = vdup_n_u8(color0[2]);
  possible_colors_v[2][0] = vdup_n_u8(color1[0]);
  possible_colors_v[2][1] = vdup_n_u8(color1[1]);
  possible_colors_v[2][2] = vdup_n_u8(color1[2]);

  uint32x4_t best_block_error_v = vdupq_n_u32(best_block_error);

  noopt(possible_colors_v, rgba_u8);

  return best_block_error_v[0];
}

Not optimized code is too long to show it (around 37 lines), because of
intrinsics.
Optimization without surroundings is correct.

ld3     {v0.8b-v2.8b}, [x0], #24
stp     d0, d1, [x1]
str     d2, [x1,#16]
ld3     {v0.8b-v2.8b}, [x0]
stp     d0, d1, [x1,#24]
str     d2, [x1,#40]

Optimization with surrounding code.

ld3     {v1.8b-v3.8b}, [x0], #24
...
stp     d0, d1, [x29,#-48]
ld3     {v0.8b-v2.8b}, [x0]
...
stp     d3, d0, [x29,#-32]
stp     d1, d2, [x29,#-16]

As you can see, it loads first part in v1-3, then stores d0, d1. Where d0 was
not even loaded, and so on.

We are using now these revisions.
CLANG_REVISION = '4e0d9925d6a3561449bdd8def27fd3f3f1b3fb9f'
CLANG_SVN_REVISION = 'n346557'
CLANG_SUB_REVISION = 2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200527/7fe86742/attachment.html>