> On Aug 11, 2021, at 11:15 AM, Richard Sandiford <richard.sandif...@arm.com> > wrote: > > 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.
This really make good sense to me. :-) > >> 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. I see. > > 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. Okay, understood. I will not handle the VLA case using pointers at this time. Per discussion with Richard Biener in the other emails, I might go the other route to special handle the _1 = .DEFERRED_INIT (4, 2, 0); alt_reloc = _1; To see whether that can resolve the issues. Let me know your opinion. Thanks a lot. Qing > > Thanks, > Richard
