Open MitalAshok opened 4 months ago
Apparently this is just unimplemented
One fix I can think of is to "speculatively infer" what an auto
type will be. When isNRVOVariable()
, we know that it is of the form return x;
or return (x);
. With a plain (possibly cv-qualified) auto
placeholder, this will be deduced to the correct type and be eligible for NRVO. With decltype(auto)
, only return x;
would be (and return (x);
would be a reference type, so not eligible). Any other form (auto*
, auto&
) would not be a class type.
Would that approach work?
Another fix could be to keep a list of possible NRVO variables re-check them after the placeholder type is deduced. This list can not be larger than the number of return statements I think
@llvm/issue-subscribers-clang-frontend
Author: Mital Ashok (MitalAshok)
@llvm/issue-subscribers-clang-codegen
Author: Mital Ashok (MitalAshok)
I think the best here would be to change NRVO from a Scope based approach, into an AST-based approach.
Looking at the assembly output for this https://godbolt.org/z/6eG7TWvvd:
Shows that the move is elided in
f1
andf3
, but not inf2
. This also happens if the placeholder isdecltype(auto)