On Thu, 1 Dec 2016, Jeff Law wrote: > On 12/01/2016 06:22 AM, Richard Biener wrote: > > > Well after removing DECL_BY_REFERENCE, verify_gimple still fails but > > > differently: > > > > > > tail-padding1.C:13:1: error: RESULT_DECL should be read only when > > > DECL_BY_REFERENCE is set > > > } > > > ^ > > > while verifying SSA_NAME nrvo_4 in statement > > > # .MEM_3 = VDEF <.MEM_1(D)> > > > nrvo_4 = __builtin_memset (nrvo_2(D), 0, 8); > > > tail-padding1.C:13:1: internal compiler error: verify_ssa failed > > > > Hmm, ok. Not sure why we enforce this. > I don't know either. But I would start by looking at tree-nrv.c since it > looks (based on the variable names) that the named-value-return optimization > kicked in. > > > > > Note that in the end this patch looks fishy -- iff we really need > > the LHS on the assignment for correctness if we have the tailcall > > flag set then what guarantees that later passes do not remove it > > again? So anybody removing a LHS would need to unset the tailcall flag? > > > > Saying again that I don't know enough about the RTL part of tailcall > > expansion. > The LHS on the assignment makes it easier to identify when a tail call is > possible. It's not needed for correctness. Not having the LHS on the > assignment just means we won't get an optimized tail call. > > Under what circumstances would the LHS possibly be removed? We know the > return statement references the LHS, so it's not going to be something that > DCE will do.
Well, I thought Prathamesh added the optimization to copy-propagate the lhs from the returned argument. So we'd have both transforms here. Of course as always the user could have written the code in this way. If the LHS is not required for correctness then I don't think we need to put it there - Pratamesh verified the call is tail-called already if marked by the tailcall pass, even if the LHS is not present. Richard.
