]> git.ipfire.org Git - thirdparty/gcc.git/commit
vectorizer: Avoid an OOB access from vectorization
authorMatthew Malcomson <matthew.malcomson@arm.com>
Thu, 20 Jul 2023 10:43:12 +0000 (11:43 +0100)
committerMatthew Malcomson <matthew.malcomson@arm.com>
Thu, 20 Jul 2023 11:07:47 +0000 (12:07 +0100)
commitc5bd0e5870aed178b7f82e7b94f59a383e7c5b4f
tree73d3cda97c9bf452d089fda26febf94eb83ef935
parent23ad5ed7432bea7c5d00837f12d8334f53c43cb4
vectorizer: Avoid an OOB access from vectorization

Our checks for whether the vectorization of a given loop would make an
out of bounds access miss the case when the vector we load is so large
as to span multiple iterations worth of data (while only being there to
implement a single iteration).

This patch adds a check for such an access.

Example where this was going wrong (smaller version of testcase added):

```
  extern unsigned short multi_array[5][16][16];
  extern void initialise_s(int *);
  extern int get_sval();

  void foo() {
    int s0 = get_sval();
    int s[31];
    int i,j;
    initialise_s(&s[0]);
    s0 = get_sval();
    for (j=0; j < 16; j++)
      for (i=0; i < 16; i++)
multi_array[1][j][i]=s[j*2];
  }
```

With the above loop we would load the `s[j*2]` integer into a 4 element
vector, which reads 3 extra elements than the scalar loop would.
`get_group_load_store_type` identifies that the loop requires a scalar
epilogue due to gaps.  However we do not identify that the above code
requires *two* scalar loops to be peeled due to the fact that each
iteration loads an amount of data from the *next* iteration (while not
using it).

Bootstrapped and regtested on aarch64-none-linux-gnu.
N.b. out of interest we came across this working with Morello.

gcc/ChangeLog:

* tree-vect-stmts.cc (get_group_load_store_type): Account for
`gap` when checking if need to peel twice.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/vect-multi-peel-gaps.c: New test.
gcc/testsuite/gcc.dg/vect/vect-multi-peel-gaps.c [new file with mode: 0644]
gcc/tree-vect-stmts.cc