On Mon, 4 Oct 2021, Qing Zhao wrote: > > > > On Oct 4, 2021, at 12:19 PM, Richard Biener <rguent...@suse.de> wrote: > > > > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao <qing.z...@oracle.com> > > wrote: > >> I have several questions on this fix: > >> > >> 1. This fix avoided expanding “.DEFERRED_INIT” when !tree_fits_uhwi_p > >> (TYPE_SIZE_UNIT (var_type)). > >> As a result, this call to .DEFERRED_INIT will NOT be expanded at all. > > > > Yes. > > Then, should we exclude such auto init during gimplification phase?
No, we do want to and can handle such variables just fine. > > > >> Then not expanding .DEFERRED_INIT in RTL expanding phase will trigger > >> more issues in later RTL phases, this looks not correct to me. (Actually, > >> with is the patch, this testing case still failed in a later RTL stage). > >> > >> So, If we really want to avoid auto-init for VLA vectors, we should not > >> add call to .DEFERRED_INIT in gimplification phase at all. > > > >> > >> > >> 2. For the added .DEFERRED_INIT: > >> > >> __SVFloat64_t f64; > >> > >> f64 = .DEFERRED_INIT (POLY_INT_CST [16, 16], 2, 0); > >> > >> What does “POLY_INT_CST[16,16]” mean? Is this a constant size? If YES, > >> what’s the value of it? If Not, can we use “memset” to expand it? > > > > When the target is a register memset doesn't work. I'm not sure the memset > > expansion path will work as-is either for aggregates with vla parts - > > Stupid question here: what does POLY_INT_CST[16,16] mean? It’s not a > constant? It's 16 * <vector-factor> where the factor is determined by the hardware implementation but fixed throughout the programs lifetime. You could think of the POLY_INT_CST expanding to a multiplication of 16 by a special hardware register. For vector types the zero-init could be done using build_zero_cst and the expand_assignment path. Also the memset path should just work as well. It's the pattern init that's a bit more complicated but I'm sure Richard will sort that out. Note TYPE_SIZE_UNIT will honor tree_fits_poly_uint64_p but for the pattern init we'd have to repeat the constant and maybe there's a clever way to do this repeating just the single pattern byte. But as said... > > but I'll leave that to Richard S. to sort out. ^^^ Richard. > > > > > Richard. > > > >> Thanks. > >> > >> Qing > >> > >> > >> > >>> On Oct 4, 2021, at 3:57 AM, Richard Biener via Gcc-patches > >>> <gcc-patches@gcc.gnu.org> wrote: > >>> > >>> This avoids ICEing for VLA vector auto-init by not initializing. > >>> > >>> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. > >>> > >>> 2021-10-04 Richard Biener <rguent...@suse.de> > >>> > >>> PR middle-end/102587 > >>> * internal-fn.c (expand_DEFERRED_INIT): Guard register > >>> initialization path an avoid initializing VLA registers > >>> with it. > >>> > >>> * gcc.target/aarch64/sve/pr102587-1.c: New testcase. > >>> * gcc.target/aarch64/sve/pr102587-2.c: Likewise. > >>> --- > >>> gcc/internal-fn.c | 3 ++- > >>> gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c | 4 ++++ > >>> gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c | 4 ++++ > >>> 3 files changed, 10 insertions(+), 1 deletion(-) > >>> create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c > >>> create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c > >>> > >>> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c > >>> index 8312d08aab2..ef5dc90db56 100644 > >>> --- a/gcc/internal-fn.c > >>> +++ b/gcc/internal-fn.c > >>> @@ -3035,7 +3035,8 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt) > >>> /* Expand this memset call. */ > >>> expand_builtin_memset (m_call, NULL_RTX, TYPE_MODE (var_type)); > >>> } > >>> - else > >>> + /* ??? Deal with poly-int sized registers. */ > >>> + else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (var_type))) > >>> { > >>> /* If this variable is in a register, use expand_assignment might > >>> generate better code. */ > >>> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c > >>> b/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c > >>> new file mode 100644 > >>> index 00000000000..2b9a68b0b59 > >>> --- /dev/null > >>> +++ b/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c > >>> @@ -0,0 +1,4 @@ > >>> +/* { dg-do compile } */ > >>> +/* { dg-options "-ftrivial-auto-var-init=zero" } */ > >>> + > >>> +void foo() { __SVFloat64_t f64; } > >>> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c > >>> b/gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c > >>> new file mode 100644 > >>> index 00000000000..4cdb9056002 > >>> --- /dev/null > >>> +++ b/gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c > >>> @@ -0,0 +1,4 @@ > >>> +/* { dg-do compile } */ > >>> +/* { dg-options "-ftrivial-auto-var-init=pattern" } */ > >>> + > >>> +void foo() { __SVFloat64_t f64; } > >>> -- > >>> 2.31.1 > >> > > > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)