> On Oct 5, 2021, at 1:25 AM, Richard Biener <rguent...@suse.de> wrote:
>
> 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.
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 <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)
