[Bug tree-optimization/116081] New: [15 Regression] Different code generation in the vectorizer with a typedef vs not

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116081

            Bug ID: 116081
           Summary: [15 Regression] Different code generation in the
                    vectorizer with a typedef vs not
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Keywords: missed-optimization, needs-bisection
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
            Blocks: 53947
  Target Milestone: ---
            Target: aarch64

Take:
```
#define N 32000
unsigned char in[N];

#ifdef TYPEDEF
typedef unsigned u32;
#else
#define u32 unsigned
#endif

u32
foo (void)
{
  u32 res = 0;
  for (int i = 0; i < N; i++)
    res += in[i];
  return res;
}

```
On aarch64 with `-march=armv9-a -O3` we get different code generation depending
on if TYPEDEF is defined or not. They are exact the same code except for the
typedef coming into the vectorizer even.

The vectorizer dup difference starts with:
```
/app/example.cpp:14:21: note:   ==> examining statement: res_6 = _2 + res_10;
/app/example.cpp:14:21: note:   get vectype for scalar type: u32
/app/example.cpp:14:21: note:   vectype: vector([4,4]) unsigned int
/app/example.cpp:14:21: note:   get vectype for smallest scalar type: u32
/app/example.cpp:14:21: note:   nunits vectype: vector([4,4]) unsigned int
/app/example.cpp:14:21: note:   nunits = [4,4]
```
On the typedef case vs:
```
/app/example.cpp:14:21: note:   ==> examining statement: res_6 = _2 + res_10;
/app/example.cpp:14:21: note:   get vectype for scalar type: unsigned int
/app/example.cpp:14:21: note:   vectype: vector([4,4]) unsigned int
/app/example.cpp:14:21: note:   nunits = [4,4]
```

Things go down hill from there.

I noticed this when I was looking to add the testcase for PR 116075 and might
be the real underlying issue there rather than the VEC_SHL_INSERT.

Note I suspect this also happens on riscv with `-march=rv64gcv` too.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations