- User Since
- Dec 17 2017, 4:06 AM (113 w, 3 d)
Sun, Feb 16
Wed, Feb 12
Sun, Feb 9
Ping again. Is there still something more to do here?
Mon, Feb 3
Updated according to comments.
Sun, Feb 2
Fix possible crash, cache regex.
Sat, Feb 1
(Removed unintended debug output in tests.)
Fri, Jan 31
I've found a corner case, as shown by clang/test/PCH/delayed-pch-instantiate.cpp, where it really is necessary to perform an instantiation in the TU. I've updated the patch to detect this and repeat these instantiations the way they would be without the patch.
Tue, Jan 28
Jan 18 2020
Handled all tests which failed because the change moved templates in -emit-llvm output.
Added a test for specialization of a template instantiated in a PCH.
Jan 16 2020
Could you please still provide input in https://reviews.llvm.org/D69585? The patch still fails in 21 OpenMP tests simply because of compiler output getting reordered, which seems to require extensive reorganizing of the tests, and I don't want to do extensive (and tedious) changes there without your input.
Jan 15 2020
In order to simplify this, I've updated the patch to remove any reference to OpenMP and I've moved that part to https://reviews.llvm.org/D72759 .
Jan 14 2020
This version uses a module based on the code posted above.
I've updated the test as requested.
Jan 13 2020
Do you need some more information about the patch? It'd be nice if this could make it into 10.0.
Jan 8 2020
Jan 7 2020
Dec 20 2019
Closing, handled in D71654.
I'm back at using gdb for the time being, so I'd have to build code with debuginfo suitable for lldb, which would take some time. But given that this is more or less the same as I did before, I don't see why this shouldn't work similarly. Thank you for getting these changes in.
Dec 11 2019
Dec 6 2019
Dec 5 2019
Nov 17 2019
It turns out that this patch may introduce unwanted changes, specifically it can cause err_specialization_after_instantiation if the specialization is done in a source file but needed already by code in the PCH. But this seems to be rare (I've encountered it only after building the Skia library with put-everything-in-the-PCH), is easy to avoid (PCHs often need little tweaks anyway) and the performance gain is very much worth it.
Nov 7 2019
Nov 6 2019
Nov 3 2019
Nov 2 2019
Let's go a different route. This patch fully passes all tests and so should be ready to be committed.
Oct 29 2019
Handled by https://reviews.llvm.org/D42303 .
Due to some technical problems with this approach and lack of feedback, I'm scratching this one. A new approach is at https://reviews.llvm.org/D69585 .
Oct 26 2019
Oct 16 2019
Thinking more about this, maybe this is really not the right place and the change should be done in BumpPtrAllocator? To me it seems rather unreasonable that it would double the allocation size only after 128 allocations. Surely by the time it has already allocated 128*4096=0.5MiB memory it could have decided to raise the allocation size much sooner?
Oh, I somehow completely missed the fact that there are 256 of those :-/. In that case my numbers are way too much. Can you easily benchmark with different numbers? I think something like 131072 for BumpPtrAllocator (to still be large enough for the mmap threshold) could be reasonable, the size for StringPool can go down to 256 or maybe can be simply dropped.
Oct 15 2019
Adjusted the testcase.
How about this one?
Removed the explicit test timeout.
Oct 12 2019
Updated misleading description.
Added a unittest.
Oct 11 2019
Oct 8 2019
Oct 6 2019
Increased default number of buckets for StringMap too.
Oct 5 2019
Sep 18 2019
Sep 17 2019
Sep 16 2019
I've noticed that the Developer Policy says that it's actually allowed to commit patches without approval for parts "that you have contributed or maintain". Given that I'm the author of -rewrite-includes I take it that it's ok if I commit this if there are no further comments.
- updated to apply to current trunk
- changed misleading condition in a test