LGTM. Build and check-llvm were both clean on my Mac for static build. Thanks!

• Simplify the loop condition

Add full diff.

LG. Please, commit it only after the runtime part is committed.

-Rebase
-Change referenced scope to function scope for variable "b" in fisson-ranges.ll

Rebase after recent SymbolTable changes. Combined with D61583, we will give good warnings for PR41693

In D59887#1508991, @thakis wrote:

Out of interest: The RecursiveASTVisitorTests are part of the ToolingTests binary while this adds a new binary TokensTest. Can you say why?

(No change needed, just curious.)

I've implemented this out of tree (for Graphcore), based loosely on the PPC implementation. IR pass based on SCEV inserts intrinsics, SDag patches them up a little, MIR pass picks appropriate instructions or falls back to a decrement and branch loop.

@kadircet what are the next steps? This is my first diff in llvm. I'm not a project member so presumably someone else will have to land it for me.

• Remove new option.

Thanks :)
Then we can change parameter type of createJITDylib to StringRef instead of std::string.

Definitely like the choice of CompositeNode owning the concrete storage!

In D62152#1508979, @efriedma wrote:

Please verify my understanding of the following is correct:

1. getTypeUnadjustedAlign() is currently only used to compute calling convention alignment for ARM and AArch64.

Yes, the only places it's called are AArch64ABIInfo::classifyArgumentType and ARMABIInfo::classifyArgumentType.

D62174 is a better solution.

2). Self hosting with -fprofile-generate hits a crash building CrashRecoveryContext.cpp. I'll try to report this.

Following a remark from @jhenderson , and in order to make sure the options filtered out are not relevant, I've been running a clang-based script to compute the application callgraph, registering all calls to `llvm::cl` commands and their parent.

In D60318#1509938, @RKSimon wrote:

@courbet Please can you ensure you have EXPENSIVE_CHECKS enabled in all your builds before going any further - you've been breaking the buildbots for well over a week now and you still haven't fixed the underlying issue.

For reference, toe output of -help with and without filtering:

The wrong patch was uploaded. Sorry for this.

@JonasToth, does this look reasonable to you? Thanks!

Of course, adding missing tests reveals shortcomings in the new code.

I managed to reduce the test a bit more: https://ghostbin.com/paste/72n9f

-Use map instead of vector for storing debug entry values
-TODO: Land a separate patch with renaming DMI-->DebugInstr

-Improve the verifier for entry values
-Add test for the verifier

-Use SPCache instead of DeclCache
-Refactor the code by addressing suggestions

LGTM, but I don't think I know the legalization code well enough to approve this.

In D42748#1510087, @MaskRay wrote:

@arichardson
If the MIPS problem was similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236165 ,
moving away from &_DYNAMIC will be a more reliable approach.
To check if an executable is dynamically linked, inspecting PT_INTERP is a better choice.

Checking if a weak undefined symbol has zero address is unreliale.
Some compilers may produce a GOT-generating relocation, some may produce an absolute relocation.
After linking, you may see the relocation resolved to static 0, or see a dynamic relocation (if at runtime there is some module providing the dynamic symbol, the weak reference will resolve to non-zero)

Quoting http://www.sco.com/developers/gabi/latest/ch4.symtab.html

The behavior of weak symbols in areas not specified by this document is implementation defined. Weak symbols are intended primarily for use in system software. Applications using weak symbols are unreliable since changes in the runtime environment might cause the execution to fail.

Regarding this patch. Actually, -Bstatic (synonym of -static in ld.bfd and lld) just means: "don't look for libfoo.so when a -lfoo is seen, before next -Bdynamic". I think it is weird to use it to decide whether we should emit .dynamic . (In the compiler drivers (gcc/clang/etc), -static mean static linking, but that is different from -Bstatic/-static in ld.bfd/lld.)

This change neither improves similarity with ld.bfd nor makes behaviors reasonable that suits lld (the internals of lld are very different from ld.bfd, some behaviors of ld.bfd may not suit lld). The logic to emit .dynamic .dynsym .dynstr etc in the 3 linkers:

lld: has_dso || --shared || --pie || --export-dynamic
gold: has_dso || --shared || --pie
bfd: (--shared || --pie) || ((not -r) && info->nointerp && (info->export_dynamic || info->dynamic)) && some (almost always true) conditions

@ed I want to knore more about your motivation to add --export-dynamic to the condition in D29982. Why do you need .dynamic in a position dependent executable for CloudABI, which has no shared object dependency on the linker command line?

-Set EnableDebugEntryValues only for a higher level of optimizations (-O1 and higher)

In D57779#1509166, @vporpo wrote:

I think the first throttling patch should implement a very simple and fast algorithm for finding the cut:

1. Add new fields to TreeEntry for Cost, ExtractCost and PredecessorsCost.
2. During getTreeCost() set the TE.Cost and TE.ExtractCost (as you did in an earlier version of the patch if I am not mistaken)
3. Do a single top-down traversal of the tree in reverse postorder and set the TE.PredecessorsCost equal to the cost of all the predecessor's costs until TE. While doing so, you can compare the cost of cutting just below TE by comparing the gather cost of TE versus the Cost + PredecessorsCost. This is very fast as you only need to visit each TreeEntry node once, so the complexity is linear to the size of the tree.
   
   For example, in slp-throttle.ll the bundle that needs to be scalarized [%add19, %sub22] has costs of Cost=1, ExtractCost = 0, PredecessorsCost=1 (because of bundle [%mul18, undef]). Cutting below the bundle has a cost of +1, while keeping it vectorized has a cost of +2 (Cost=1 + PredecessorsCost=1).
   
   This should be good-enough for most simple cases. We can improve it later, if needed, with follow-up patches. What do you think?

yes, Looks good.

Ping. Is anyone willing to be the reviewer for this revision?

This ideas in this revisions are gradually being committed.

And this patch actually fixes the bug. Thanks.

I might be doing something wrong but this seems to have broken BUILD_SHARED_LIBS for me in that even with that enabled clang is built as a bunch of static libraries linked into a shared one like this patch is supposed to make it do, while I thought that BUILD_SHARED_LIBS was supposed to make it create a bunch of shared libraries as it did before with libclang and still does with libLLVM.

Looks good to me.