- User Since
- Jan 2 2013, 4:34 PM (306 w, 2 d)
The main reservation I have about landing this is whether to make it more generic and abstracted. I kind of feel like the main SymbolSerializer class should be powerful enough to do all these optimizations for us, or maybe some replacement for it.
I collected statistics:
The summary is that links in Chromium get 32% faster, but object files grow by 7%. There is no compile time impact. Check it out for more details.
Wed, Nov 14
I ended up finding these instructions accidentally when searching for other monorepo related stuff, and I followed these instructions, and they worked. Thanks for writing them up!
I'd say feel free to commit typo fixes like this in the future. I'd avoid fixing typos where there is spelling disagreement, like "prolog vs prologue", so just use your best judgement as always.
It went green with my change here:
Tue, Nov 13
I think this broke the windows selfhost:
Sorry, I didn't realize this was waiting on my review. It looks like this is mostly about localescape, so let's change the patch description and code to be about that.
+1 for writing it as you have it, it's what clang-format does, and so far as I know it's the prevailing style.
Adding -Wno-cast-function-type seems reasonable, but we should do it more carefully.
Mon, Nov 12
Fri, Nov 9
Can you add a quick test to the lit test suite for this? Shouldn't be too hard, make some dirs, cd into and out, pwd, filecheck the output.
Sorry, I lost track of this.
I guess you should update the commit message to say "monorepo-root" instead of "monorepo-top". Otherwise, neat!
Threading a new options argument through mangleType that includes QualifierMangleMode as well as these obj-c options seems reasonable.
Thu, Nov 8
Wed, Nov 7
- Elaborate on comdats in a comment
I was going to consult @zturner about the state of Python 3 in LLDB, but that's not really related to your change. I think it's fine. lgtm
I hadn't realized that Dexter knew how to drive VS tools. I'll have to go read more and get back to you all.
Tue, Nov 6
Traditionally, LLDB has resisted efforts to more tightly couple it with LLVM. Many of the contributors at Apple seem to prefer to build LLVM separately and then build against that with the LLDB xcode project. You can see how that would disincentivize you from contributing to LLVM first. And in fairness, sometimes LLVM people object to adding extra complexity to Support when it's only used in LLDB. And, as with lib/DebugInfo/DWARF, sometimes code gets hoisted to LLVM without refactoring LLDB to use it. So, there's plenty of work to go around. :)
- Fix thinko
lgtm with some minor suggestions
We came up with a different solution for this called SEH_Epilogue. It basically inserts a nop if the last real instruction was a call. It's slightly complicated because it looks backwards across empty basic blocks and things. You can see it here:
Mon, Nov 5
Fri, Nov 2
Looks good, but when you commit it, you probably will want to keep an eye out for warnings or build breakages in other configurations. This code will be compiled with GCC, MSVC, and clang, and I can imagine a few ways the WindowsSupport.h code could raise warnings.