If you want to build this patch, please apply D72301 before. I will try and make it work without it soon.

Sort PathRank candidates by minimal distance

Don't dispatch materialization for trivial modules to the thread pool

Submit actual module keys and sort getAllModulePaths() by ID

Fix GUID when instrumenting functions with local linkage

Respect environment variables CFLAGS and EXEC_ARGS in the bench script

Indeed, that sounds like a better solution.

Pardon, apparently the last update was missing the actual code changes. Trying again.

Avoid concurrent addModule() calls, improve ranking algorithm in discovery, add multi-threaded bitcode parsing

Make LookaheadLevels and LookupOnAdd configurable

This was fixed with 2cdb18afda8

In D72486#1814233, @lhames wrote:

Hi Stefan. Thanks for posting this! I’m out on vacation this week, but looking forward to reviewing when I get back to the office next week.

DataLayout can be owned by MangleWrapper

Use runAsMain() utility function from ExecutionUtils

I was about to say enjoy your time off and have a look here on Monday: D72563 I guess we don't need it anymore :)
Is there a particular reason to pass lli as the program name instead of the main source file? Not saying that this made a lot of sense in the first place, just wondering.

Fix: Protect the set of parsed module IDs from concurrent access

Polishing, comments, cosmetics

Make it configurable whether the symbol generator can nugde things into discovery

Make DiscoveryFlagsPerBatch and MemFence settings configurable

Workaround: parsed module requested but waiting in JITDylib::define()

Pull in new modules also for global variables

Looks like this broke argument handling in orc-lazy mode for lli.
Given a bitcode version of a main2.c like this:

#include <stdio.h>
int main(int argc, char *argv[]) {
  for (int i = 0; i < argc; i++)
    printf("%d: %s\n", argv[i]);
  return 0;
}

Sample output:

> ./ThinLtoJIT -debug -debug-only="thinltojit" -compile-threads=2 example.bc tinyexpr.bc compile.bc free.bc eval.bc
1 new flags raised
Nudged 1 new functions into discovery
Instrumented 1 new functions in module example.bc
Generator: Added 1 new modules
Nudged 1 new functions into discovery
DiscoveryThread: 3 new modules (1 known modules)
1 new flags raised
DiscoveryThread: 0 new modules (3 known modules)
1 new flags raised
DiscoveryThread: 0 new modules (4 known modules)
Instrumented 3 new functions in module tinyexpr.bc
1 new flags raised
DiscoveryThread: 0 new modules (3 known modules)
Instrumented 23 new functions in module compile.bc
Generator: Added 0 new modules
11 new flags raised
DiscoveryThread: 0 new modules (3 known modules)
1 new flags raised
DiscoveryThread: 0 new modules (0 known modules)
Instrumented 1 new functions in module eval.bc
1 new flags raised
DiscoveryThread: 0 new modules (1 known modules)
Instrumented 2 new functions in module free.bc
Generator: Added 0 new modules
2 new flags raised
DiscoveryThread: 0 new modules (1 known modules)
2 new flags raised
DiscoveryThread: 0 new modules (0 known modules)
The expression:
	sqrt(5^2+7^2+11^2+(8-2)^2)
evaluates to:
	15.198684
Discovery flags stats
Alloc:  4096
Used:     32
Fired:    21

Polishing

I'd recommend to be careful when making a change of this size. There are a lot of possible configurations.
If you split it up into a few smaller and more dedicated commits, you will make your life easier. Otherwise someone might just revert everything if this happens to break a bot.

Right, this was a missing deprecation change. Thanks for posting! Lang fixed it the same day, so I guess we can abandon this review.

This change was proposed in review D65934

Did this land?

Achieve the same via extra HINT to find_package(Clang ...)

In D65939#1620780, @labath wrote:

So, why doesn't LLVM_ENABLE_WERROR suffice? It looks like that ought to work even in standalone builds...

Right

Originally introduced with D31969. LGTM. Maybe we can remove even more?

In D65798#1618609, @labath wrote:

Making it so that the clang is automatically found it if happens to be next to llvm seems like a reasonable thing to me. I have no idea what would be the canonical cmake way to do that...

Update documentation to mention multiple provided build trees and the usage of Clang_DIR

What do you think?

Change comment and condition to only infer Clang_DIR if it exists.

Solutions are clearly favorable over workarounds like this, but I couldn't find one. Xcode has a mechanism called sign on copy which seems to be the native way to avoid this problem, but I couldn't get it to work with LLDB, because I want to copy the build output of a target and this caused a cyclic dependency. I didn't find more information about it and there seems to be no way to generate this behavior with CMake. The only way around seems to be a custom script, but that is no better than the workaround here.

Improve warning message

In D65566#1611007, @JDevlieghere wrote:

Is there a way to use the debugserver in the framework instead?

Checked with:

> xcodebuild -configuration Release -target debugserver
> codesign -dv Release/bin/LLDB.framework/Versions/A/Resources/debugserver
> codesign -dv Release/bin/debugserver

In D65438#1608900, @thakis wrote:

This broke the sphinx bot

This was fixed quite some time ago.

Yes, agree! Hopefully we will move on to a newer version (3.9?) some time soon, but that needs a broader discussion first.

If we want to add git at all, we should probably mention it somewhere else. I'm not sure where that would be - I suppose somewhere where it makes sense to worry about the minimum version, e.g. where the git-llvm script is concerned.

Undo Compiling -> Working with

Remove lldb documentation updates I just added accidentally

Move git version comment into a footnote in git-llvm section

Hi Lang, I am getting these warnings from ninja docs-llvm-html:

@clayborg I added a direct link to Xcode project generation here. Is that fine?

Add lld note to Windows section

Thanks for your feedback.

Feedback and polishing; latest rendered output here: http://tiny.cc/i5ncaz

Hi Greg, thanks for your feedback.

Address recent feedback

In D65330#1602786, @jryans wrote:

On http://releases.llvm.org/, for some recent versions like 8.0.0, the "Documentation" column has separate versioned links for "llvm clang lld clang-extra libc++ polly", but lldb doesn't appear there.