Summary:
This revision fixes a -Wzero-length-array compile error that
caused e459596917 which reverted
78f9e5d098.
Also fixes a struct vs class mismatch that broke compilation with
-Werror for Windows that caused
57397eba7a.
This revision adds padding for 1-D Vector in the common case of x86
execution with a stadard data layout. This supports properly interfacing
codegen with arrays of e.g. `vector<9xf32>`.
Such vectors are already assumed padded to the next power of 2 by LLVM
codegen with the default x86 data layout:
```
define void @test_vector_add_1d_2_3(<3 x float>* nocapture readnone %0,
<3 x float>* nocapture readonly %1, i64 %2, i64 %3, i64 %4, <3 x float>*
nocapture readnone %5, <3 x float>* nocapture readonly %6, i64 %7, i64
%8, i64 %9, <3 x float>* nocapture readnone %10, <3 x float>* nocapture
%11, i64 %12, i64 %13, i64 %14) local_unnamed_addr {
%16 = getelementptr <3 x float>, <3 x float>* %6, i64 1
%17 = load <3 x float>, <3 x float>* %16, align 16
%18 = getelementptr <3 x float>, <3 x float>* %1, i64 1
%19 = load <3 x float>, <3 x float>* %18, align 16
%20 = fadd <3 x float> %17, %19
%21 = getelementptr <3 x float>, <3 x float>* %11, i64 1
```
The pointer addressing a `vector<3xf32>` is assumed aligned `@16`.
Similarly, the pointer addressing a `vector<65xf32>` is assumed aligned
`@512`.
This revision allows using objects such as `vector<3xf32>` properly with
the standard x86 data layout used in the JitRunner. Integration testing
is done out of tree, at the moment such testing fails without this
change.
Differential Revision: https://reviews.llvm.org/D75459
63b2ff07e8