Woops. Submitted that last comment too early. Editing it on Phab. On Fri, May 4, 2018 at 2:31 AM, Eric Fiselier via Phabricator < revi...@reviews.llvm.org> wrote:
> EricWF added a comment. > > In https://reviews.llvm.org/D45476#1087446, @cfe-commits wrote: > > > I think you and Richard agreed that you weren’t going to synthesize a > whole > > expression tree at every use of the operator, and I agree with that > > decision. That’s very different from what I’m asking you to do, which > is to > > synthesize in isolation a call to the copy-constructor. > > > Perhaps. My apologies. I'm still quite new to the Clang internals. I > appreciate your patience. > > > There are several places in the compiler that require these implicit > copies which aren’t just > > normal expressions; this is the common pattern for handling them. The > > synthesized expression can be emitted multiple times, and it can be > freely > > re-synthesized in different translation units instead of being > serialized. > > I'm not sure this is always the case. For example: > > // foo.h > #include <compare> > > struct Foo { > int x; > }; > inline auto operator<=>(Foo const& LHS, Foo const& RHS) { > > } > // foo.cpp > #include <foo.h> // imported via module. > auto bar(Foo LHS, Foo RHS) { > return > } > > > > > You’re already finding and caching a constructor; storing a > > CXXConstructExpr is basically thr same thing, but in a nicer form that > > handles more cases and doesn’t require as much redundant code in IRGen. > > I'm not actually caching the copy constructor. And I disagree that storing > a > `CXXConstructExpr` is essentially the same thing. I can lookup the > `CXXConstructorDecl` without `Sema`, > but I can't build a `CXXConstructExpr` without it. > > > STLs *frequently* make use of default arguments on copy constructors (for > > allocators). I agree that it’s unlikely that that would happen here, but > > that’s precisely because it’s unlikely that this type would ever be > > non-trivial. > > > > Mostly, though, I don’t understand the point of imposing a partial set of > > non-conformant restrictions on the type. It’s easy to support an > arbitrary > > copy constructor by synthesizing a CXXConstructExpr, and this will > > magically take care of any constexpr issues, as well as removing the > need > > for open-coding a constructor call. > > > > The constexpr issues are that certain references to constexpr variables > of > > literal type (as these types are likely to be) are required to not > ODR-use > > the variable but instead just directly produce the initializer as the > > expression result. That’s especially important here because (1) > existing > > STL binaries will not define these variables, and we shouldn’t create > > artificial deployment problems for this feature, and (2) we’d really > rather > > not emit these expressions as loads from externally-defined variables > that > > the optimizer won’t be able to optimize. > > > > John. > > > https://reviews.llvm.org/D45476 > > > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits