Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors
> On Oct 5, 2021, at 1:25 AM, Richard Biener wrote:
>
> On Mon, 4 Oct 2021, Qing Zhao wrote:
>
>>
>>
>>> On Oct 4, 2021, at 12:19 PM, Richard Biener wrote:
>>>
>>> On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao
>>> 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 * 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
> 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
>
> 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 000..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 000..4cdb9056002
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/sve
Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors
On Tue, 5 Oct 2021, Richard Sandiford wrote: > Richard Biener via Gcc-patches writes: > > On Mon, 4 Oct 2021, Qing Zhao wrote: > > > >> > >> > >> > On Oct 4, 2021, at 12:19 PM, Richard Biener wrote: > >> > > >> > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao > >> > 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 * 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 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 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 registe
Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors
Richard Biener via Gcc-patches writes: > On Mon, 4 Oct 2021, Qing Zhao wrote: > >> >> >> > On Oct 4, 2021, at 12:19 PM, Richard Biener wrote: >> > >> > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao >> > 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 * 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
Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors
On Mon, 4 Oct 2021, Qing Zhao wrote:
>
>
> > On Oct 4, 2021, at 12:19 PM, Richard Biener wrote:
> >
> > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao
> > 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 * 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
> >>> 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
> >>>
> >>> 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 000..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 000..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
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuer
Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors
> On Oct 4, 2021, at 12:19 PM, Richard Biener wrote:
>
> On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao
> 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
>>> 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
>>>
>>> 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 000..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 000..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
>>
>
Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors
On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao 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
>> 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
>>
>> 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 000..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 000..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
>
Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors
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
> 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
>
> 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 000..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 000..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
[PATCH] middle-end/102587 - avoid auto-init for VLA vectors
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
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 000..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 000..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
