adams381 wrote: Not ugly to write -- for a top-level scalar array it's a `private constant [n x T]` prefix and one ctor that memcpy's it in, and it kills the `cir.global_view` redirect (`tz_split_basis`) you don't like.
```llvm @s = global [1000 x i32] zeroinitializer, align 16 @s.init = private constant [3 x i32] [i32 1, i32 2, i32 3] ; @llvm.global_ctors runs a ctor that memcpy's 12 bytes from @s.init into @s ``` What I don't love is where `@s` ends up. The current split keeps it a `constant` in `.rodata` like classic; the ctor path moves it to `.bss` with a startup memcpy and it stays there -- `opt -O2` doesn't fold it back to a constant on either external or `internal` linkage. So for a top-level `const` array that's a regression versus classic, traded for dropping the redirect. And the redirect only goes away for top-level arrays anyway; nested records and arrays-of-records still struct-split through `initContainsSplittableArray`. Nothing hits the threshold today, and the regression only shows up once CIRGen emits the array-typed `trailing_zeros` form, so there's time to sit on it. I'll leave the current split up while you think it over, and switch to the ctor path if that's where you land. https://github.com/llvm/llvm-project/pull/205918 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
