Qing Zhao <qing.z...@oracle.com> writes: >> On Aug 11, 2021, at 4:02 AM, Richard Sandiford <richard.sandif...@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
