[PATCH] middle-end/102587 - avoid auto-init for VLA vectors

[Richard Biener]

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)