* [PATCH] middle-end/102587 - avoid auto-init for VLA vectors @ 2021-10-04 8:57 Richard Biener 2021-10-04 17:00 ` Qing Zhao 0 siblings, 1 reply; 8+ messages in thread From: Richard Biener @ 2021-10-04 8:57 UTC (permalink / raw) To: gcc-patches 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 <rguenther@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors 2021-10-04 8:57 [PATCH] middle-end/102587 - avoid auto-init for VLA vectors Richard Biener @ 2021-10-04 17:00 ` Qing Zhao 2021-10-04 17:19 ` Richard Biener 0 siblings, 1 reply; 8+ messages in thread From: Qing Zhao @ 2021-10-04 17:00 UTC (permalink / raw) To: Richard Biener; +Cc: gcc-patches 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. 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? 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 <rguenther@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors 2021-10-04 17:00 ` Qing Zhao @ 2021-10-04 17:19 ` Richard Biener 2021-10-04 17:24 ` Qing Zhao 0 siblings, 1 reply; 8+ messages in thread From: Richard Biener @ 2021-10-04 17:19 UTC (permalink / raw) To: Qing Zhao; +Cc: gcc-patches On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao <qing.zhao@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 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 - but I'll leave that to Richard S. to sort out. 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 <rguenther@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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors 2021-10-04 17:19 ` Richard Biener @ 2021-10-04 17:24 ` Qing Zhao 2021-10-05 6:25 ` Richard Biener 0 siblings, 1 reply; 8+ messages in thread From: Qing Zhao @ 2021-10-04 17:24 UTC (permalink / raw) To: Richard Biener; +Cc: gcc-patches > On Oct 4, 2021, at 12:19 PM, Richard Biener <rguenther@suse.de> wrote: > > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao <qing.zhao@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? > >> 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? Qing > but I'll leave that to Richard S. to sort out. > > 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 <rguenther@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 >> > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors 2021-10-04 17:24 ` Qing Zhao @ 2021-10-05 6:25 ` Richard Biener 2021-10-05 8:28 ` Richard Sandiford 2021-10-05 15:33 ` Qing Zhao 0 siblings, 2 replies; 8+ messages in thread From: Richard Biener @ 2021-10-05 6:25 UTC (permalink / raw) To: Qing Zhao; +Cc: gcc-patches On Mon, 4 Oct 2021, Qing Zhao wrote: > > > > On Oct 4, 2021, at 12:19 PM, Richard Biener <rguenther@suse.de> wrote: > > > > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao <qing.zhao@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 <rguenther@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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors 2021-10-05 6:25 ` Richard Biener @ 2021-10-05 8:28 ` Richard Sandiford 2021-10-05 8:33 ` Richard Biener 2021-10-05 15:33 ` Qing Zhao 1 sibling, 1 reply; 8+ messages in thread From: Richard Sandiford @ 2021-10-05 8:28 UTC (permalink / raw) To: Richard Biener via Gcc-patches; +Cc: Qing Zhao, Richard Biener Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On Mon, 4 Oct 2021, Qing Zhao wrote: > >> >> >> > On Oct 4, 2021, at 12:19 PM, Richard Biener <rguenther@suse.de> wrote: >> > >> > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao <qing.zhao@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. > > ^^^ Yeah, I'm hoping to get to this in stage 3 :-) The PR is still open until then and I agree the bypass is a good idea in the meantime. Thanks, Richard ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors 2021-10-05 8:28 ` Richard Sandiford @ 2021-10-05 8:33 ` Richard Biener 0 siblings, 0 replies; 8+ messages in thread From: Richard Biener @ 2021-10-05 8:33 UTC (permalink / raw) To: Richard Sandiford; +Cc: Richard Biener via Gcc-patches, Qing Zhao On Tue, 5 Oct 2021, Richard Sandiford wrote: > Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > > On Mon, 4 Oct 2021, Qing Zhao wrote: > > > >> > >> > >> > On Oct 4, 2021, at 12:19 PM, Richard Biener <rguenther@suse.de> wrote: > >> > > >> > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao <qing.zhao@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. > > > > ^^^ > > Yeah, I'm hoping to get to this in stage 3 :-) > > The PR is still open until then and I agree the bypass is a good idea in > the meantime. Btw, I've just completed testing the following which restores init on aarch64 (when you specify -march=armv8.3-a+sve, otherwise we ICE on SVE register uses) and also restores the init of the VLA case that was lost. The only caveat is that we use zero-init for the VLA vectors even with pattern init - that's something to improve. Also initializing from build_zero_cst might explode later for poly-int sized things I cannot imagine right now ;) Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. Richard. From bd73fdacf72563ce27edbcdfc0d06d5378339f85 Mon Sep 17 00:00:00 2001 From: Richard Biener <rguenther@suse.de> Date: Tue, 5 Oct 2021 09:28:20 +0200 Subject: [PATCH] More .DEFERRED_INIT expansion rework To: gcc-patches@gcc.gnu.org This avoids looking at the type size and instead uses the size as passed to .DEFERRED_INIT to determine the size of the non-MEM to be initialized. It also arranges for possibly poly-int inits to always use zero-initialization rather than not initializing and when we need to pun puns the LHS instead of the constant value. That correctly initializes the variable-size typed array in the testcase for PR102285 and the SVE vector in PR102587 where for the testcase I needed to add a SVE capable -march as to not ICE later. 2021-10-05 Richard Biener <rguenther@suse.de> PR middle-end/102587 PR middle-end/102285 * internal-fn.c (expand_DEFERRED_INIT): Fall back to zero-initialization as last resort, use the constant size as given by the DEFERRED_INIT argument to build the initializer. * gcc.target/aarch64/sve/pr102587-1.c: Add -march=armv8.3-a+sve. * gcc.target/aarch64/sve/pr102587-2.c: Likewise. --- gcc/internal-fn.c | 27 ++++++++++--------- .../gcc.target/aarch64/sve/pr102587-1.c | 2 +- .../gcc.target/aarch64/sve/pr102587-2.c | 2 +- 3 files changed, 17 insertions(+), 14 deletions(-) diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c index 110145218b9..78db25bbac4 100644 --- a/gcc/internal-fn.c +++ b/gcc/internal-fn.c @@ -3038,19 +3038,18 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt) /* Expand this memset call. */ expand_builtin_memset (m_call, NULL_RTX, TYPE_MODE (var_type)); } - /* ??? Deal with poly-int sized registers. */ - else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (var_type))) + else { - /* If this variable is in a register, use expand_assignment might - generate better code. */ - tree init = build_zero_cst (var_type); - unsigned HOST_WIDE_INT total_bytes - = tree_to_uhwi (TYPE_SIZE_UNIT (var_type)); - - if (init_type == AUTO_INIT_PATTERN) + /* If this variable is in a register use expand_assignment. */ + tree init; + if (tree_fits_uhwi_p (var_size) + && (init_type == AUTO_INIT_PATTERN + || !is_gimple_reg_type (var_type))) { + unsigned HOST_WIDE_INT total_bytes = tree_to_uhwi (var_size); unsigned char *buf = (unsigned char *) xmalloc (total_bytes); - memset (buf, INIT_PATTERN_VALUE, total_bytes); + memset (buf, (init_type == AUTO_INIT_PATTERN + ? INIT_PATTERN_VALUE : 0), total_bytes); if (can_native_interpret_type_p (var_type)) init = native_interpret_expr (var_type, buf, total_bytes); else @@ -3058,10 +3057,14 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt) tree itype = build_nonstandard_integer_type (total_bytes * BITS_PER_UNIT, 1); wide_int w = wi::from_buffer (buf, total_bytes); - init = build1 (VIEW_CONVERT_EXPR, var_type, - wide_int_to_tree (itype, w)); + init = wide_int_to_tree (itype, w); + /* Pun the LHS to make sure its type has constant size. */ + lhs = build1 (VIEW_CONVERT_EXPR, itype, lhs); } } + else + /* Use zero-init also for variable-length sizes. */ + init = build_zero_cst (var_type); expand_assignment (lhs, init, false); } diff --git a/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c b/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c index 2b9a68b0b59..af2ae59e5d4 100644 --- a/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c +++ b/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c @@ -1,4 +1,4 @@ /* { dg-do compile } */ -/* { dg-options "-ftrivial-auto-var-init=zero" } */ +/* { dg-options "-march=armv8.3-a+sve -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 index 4cdb9056002..8c9d9908bac 100644 --- a/gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c +++ b/gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c @@ -1,4 +1,4 @@ /* { dg-do compile } */ -/* { dg-options "-ftrivial-auto-var-init=pattern" } */ +/* { dg-options "-march=armv8.3-a+sve -ftrivial-auto-var-init=pattern" } */ void foo() { __SVFloat64_t f64; } -- 2.31.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors 2021-10-05 6:25 ` Richard Biener 2021-10-05 8:28 ` Richard Sandiford @ 2021-10-05 15:33 ` Qing Zhao 1 sibling, 0 replies; 8+ messages in thread From: Qing Zhao @ 2021-10-05 15:33 UTC (permalink / raw) To: Richard Biener; +Cc: gcc-patches > On Oct 5, 2021, at 1:25 AM, Richard Biener <rguenther@suse.de> wrote: > > On Mon, 4 Oct 2021, Qing Zhao wrote: > >> >> >>> On Oct 4, 2021, at 12:19 PM, Richard Biener <rguenther@suse.de> wrote: >>> >>> On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao <qing.zhao@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. Okay. > >>> >>>> 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. So, it’s a fixed value but cannot be treated as an constant during compilation time? > > 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. Okay, so, now we use zeroes for both zero-init and pattern-init for variable with “vector types”? Shall we document this fact? > > 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. > > ^^^ okay. thanks. Qing > > 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 <rguenther@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 <rguenther@suse.de> > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, > Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg) ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-10-05 15:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-04 8:57 [PATCH] middle-end/102587 - avoid auto-init for VLA vectors Richard Biener 2021-10-04 17:00 ` Qing Zhao 2021-10-04 17:19 ` Richard Biener 2021-10-04 17:24 ` Qing Zhao 2021-10-05 6:25 ` Richard Biener 2021-10-05 8:28 ` Richard Sandiford 2021-10-05 8:33 ` Richard Biener 2021-10-05 15:33 ` Qing Zhao
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).