This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Use _Lazy in tuple constructors
ClosedPublic

Authored by ldionne on Aug 23 2022, 3:35 PM.

Details

Reviewers
huixie90
ldionne
Group Reviewers
Restricted Project
Commits
rG0106ae3cce01: [libc++] Use _Lazy in tuple constructors
Summary

This reduces the number of instantiations and also avoid blowing up
past the fold-expression limit of Clang.

This is NOT a general statement that we should strive to stay within
Clang's (sometimes way too small) limits, however in this case the
change will reduce the number of template instantiations while at the
same time doing that, which is good.

Diff Detail

Event Timeline

ldionne created this revision.Aug 23 2022, 3:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2022, 3:35 PM
ldionne requested review of this revision.Aug 23 2022, 3:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2022, 3:35 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript

Thanks for the fix!

libcxx/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/recursion_depth.pass.cpp
24

I think this would call the move constructor tuple(tuple&&) = default;, which is always going to pass. Those constructors we manually write take a different types of tuple. Would be worth to create a type that is convertible from integral_constant and test tuple of those constructed from LargeTuple?

29

Why does t3 == t4 not work?

43

The new move constructor takes const Tuple<...>&&. It would be good to have a test for that too

LargeTuple t5(std::move(std::as_const(t3)));
ldionne marked 3 inline comments as done.Sep 19 2023, 12:12 PM
ldionne added inline comments.
libcxx/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/recursion_depth.pass.cpp
29

We seem to blow the constexpr stack. I suggest not trying to fix that in this patch in order to land this.

ldionne updated this revision to Diff 557068.Sep 19 2023, 12:12 PM
ldionne marked an inline comment as done.

Rebase. Fix tests and comments.

huixie90 accepted this revision as: huixie90.Sep 19 2023, 1:43 PM

Thanks LGTM!

libcxx/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/recursion_depth.pass.cpp
20–21

unused and remove?

28

nit: for completeness , perhaps we can have another test to test the const tuple& overload? (although source code is not in this patch)

TargetTuple t5 = std::as_const(tuple);
ldionne updated this revision to Diff 557076.Sep 19 2023, 2:13 PM
ldionne marked 2 inline comments as done.

Address comments.

ldionne updated this revision to Diff 557336.Sep 25 2023, 3:32 PM

Reduce to tuples of size 512, otherwise we don't have enough memory on some builders.

ldionne accepted this revision.Sep 26 2023, 6:23 AM
This revision is now accepted and ready to land.Sep 26 2023, 6:23 AM
This revision was landed with ongoing or failed builds.Sep 26 2023, 6:24 AM
This revision was automatically updated to reflect the committed changes.

FYI, I see that this change had the effect, that compiling std/utilities/tuple/tuple.tuple/tuple.cnstr/recursion_depth.pass.cpp now uses 2.3 GB of memory in Clang, while it previously only used 200 MB memory to compile it.

I guess that particular testcase is a rather extreme case, but I just wanted to doublecheck that this was expected behaviour.

philnik added a subscriber: philnik.Nov 3 2023, 5:00 AM

FYI, I see that this change had the effect, that compiling std/utilities/tuple/tuple.tuple/tuple.cnstr/recursion_depth.pass.cpp now uses 2.3 GB of memory in Clang, while it previously only used 200 MB memory to compile it.

I guess that particular testcase is a rather extreme case, but I just wanted to doublecheck that this was expected behaviour.

Did the test changes affect the memory usage or the code changes?

FYI, I see that this change had the effect, that compiling std/utilities/tuple/tuple.tuple/tuple.cnstr/recursion_depth.pass.cpp now uses 2.3 GB of memory in Clang, while it previously only used 200 MB memory to compile it.

I guess that particular testcase is a rather extreme case, but I just wanted to doublecheck that this was expected behaviour.

Did the test changes affect the memory usage or the code changes?

Good point. It looks like this was caused by the test change, not by the header itself.

The old test file together with the new header uses the same amount of memory to compile as before.