Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Richard Sandiford <richard.sandiford@arm.com>]

Qing Zhao <qing.zhao@oracle.com> writes:
>> On Aug 11, 2021, at 4:02 AM, Richard Sandiford <richard.sandiford@arm.com> wrote:
>>> I came up with the following solution:
>>> 
>>> Define the IFN_DEFERRED_INIT function as:
>>> 
>>>   LHS = DEFERRED_INIT (SIZE of the DECL, INIT_TYPE, IS_VLA);
>>> 
>>>   if IS_VLA is false, the LHS is the DECL itself,
>>>   if IS_VLA is true, the LHS is the pointer to this DECL that created by
>>>   gimplify_vla_decl.
>>> 
>>> 
>>> The benefit of this solution are:
>>> 
>>> 1. Resolved the invalid IR issue;
>>> 2. The call stmt carries the address of the VLA natually;
>>> 
>>> The issue with this solution is:
>>> 
>>> For VLA and non-VLA, the LHS will be different, 
>>> 
>>> Do you see any other potential issues with this solution?
>> 
>> The idea behind the DECL version of the .DEFERRED_INIT semantics was
>> that .DEFERRED_INIT just returns a SIZE-byte value that the caller
>> then assigns to a SIZE-byte lhs (with the caller choosing the lhs).
>> .DEFEREED_INIT itself doesn't read or write memory and so can be const,
>> which in turn allows alias analysis to be more precise.
> Yes. That’s right.
>
>> 
>> If we want to handle the VLA case using pointers instead then I think
>> that needs to be a different IFN.
>> 
>> If we did handle the VLA case using pointers (not expressing an opinion
>> on that), then it would be the caller's job to allocate the VLA and work
>> out the address of the VLA;
>
> the current routine “gimplify_vla_decl” has done this already:
>
> It created a temporary variable for the address of the VLA, and created a call to “alloca” to allocate the VLA.

Right, that's what I mean.  It's this alloca that allocates the VLA
and determines its address.  This address is therefore logically an
input rather than an output to the following zero/pattern initialisation.

In C you wouldn't write:

  addr = alloca(size);
  addr = initialise(size);

to allocate and initialise a size-byte buffer, because initialise()
would need to know the address of the memory it's supposed to initialise.
The same is true for this gimple code.

> My -ftrivial-auto-var-init work just try to use the “address variable of the VLA” in the new .DEFERRED_INIT call to carry it to RTL expansion phase.
>
>
>> this isn't something that .DEFERRED_INIT
>> would work out on the caller's behalf.  The address of the VLA should
>> therefore be an argument to the new IFN, rather than something that
>> the IFN returns.
>
> Then what’s the LHS of this call? Currently the major issue is the LHS is invalid gimple.

For this (different, address-taking, VLA-only) IFN, there would be no lhs.
The IFN would be similar to a memset.

Like I say, this is all hypothetical, based on “if we did handle the VLA
case using pointers”.  As discussed, it would make alias analysis less
precise.  I was just answering the question about whether there were
potential issues.

Thanks,
Richard