Tweak description.

@eugenis @vitalybuka @kcc Is it okay to land this?

I don't really understand what this is getting at, so I'd recommend rewording this a bit for clarity. Would something along the lines of this capture the intended meaning?:

Remove unneeded macro undefinition.

@yln Is the comment I added clear enough?

Add comment explaining loading of dylib.

In D77693#1968323, @arsenm wrote:

Can merge with the existing store tests

Can merge with the existing store tests

Fix build errors. Missed -DLLVM_ENABLE_PROJECTS in previous local test builds.

Add extra verifier check

@efriedma Would you please take a look at this patch? Any feedback is appreciated.

Name anonymous namespace.

Regarding PackedVector::operator==, this code is covered by the PackedVector unit test but not thoroughly enough to catch the bug.

In D77446#1967893, @vsk wrote:

Thanks, lgtm!

Later on, I think we'll want to insert DBG_VALUE insts as well, but this looks very useful as-is.

This looks good to me, except that instead of leaving all the other variants of AddCommand, they should funnel through the one that takes the most arguments. It was poor form to leave two around and more so now that there's three.

Ping ping. This will fix some existing issues reported by users :)

rebase. Mention asmparser in commit message

Use IR rather than C for the clang test.
I was able to simplify the clang patch somewhat as a "lowering error" isn't any more revealing than just emitting a generic "backend error".

In D72194#1965731, @MaskRay wrote:

I am mostly fine with the LLVM CodeGen/MC side change, but the clang side change can probably be moved to a subsequent change. For the test/clang/CodeGen/ test, we may want to test .ll -> .s instead, not .c -> .s

rebase, mention codegen in commit message

In D77611#1968227, @dblaikie wrote:

Looks like GCC warns on everything but the last unused expression (the last one being the return statement) - only warning on that last one if it's ultimately unused by the statement expression function call, as it were (& is annotated warn_unused_result). Basically, it models it like a function in a way that Clang perhaps does not?

LGTM

fix permissions issue

Looks like GCC warns on everything but the last unused expression (the last one being the return statement) - only warning on that last one if it's ultimately unused by the statement expression function call, as it were (& is annotated warn_unused_result). Basically, it models it like a function in a way that Clang perhaps does not?

rebase, mention arm in commit message

These are new tests how do you get the generic lld driver to work?

Remove separately-committed cleanup commits.

update commit message to mention bitreader

In D77678#1968093, @nicolasvasilache wrote:

The utility function part looks like quite a massive change for just the purpose of getting the xxxForOp from their respective induction variables.
Why is this a good tradeoff (also, it is not tested FWICT)?

In D77498#1968123, @sidneym wrote:

Since this isn't something that can be always known in advance I think the testcase should just be removed.

In D77672#1968122, @jrtc27 wrote:

In D77672#1967700, @MaskRay wrote:

My immediate reaction is "isn't Sparc an abandoned architecture?" See https://en.wikipedia.org/wiki/SPARC and https://lists.freebsd.org/pipermail/freebsd-sparc64/2020-January/010192.html

Though, no objection. You may still need some basic tests, similar to test/ELF/ppc32-* I tried hard to keep the number of tests small yet complete. Does sparc64 use TLS variant 2?

For FreeBSD, yes, and mostly within LLVM (certainly nobody really uses LLD). The non-release Debian architecture is still going strong though. SPARC (32-bit and 64-bit) is basically the same as IA-32 (although not with the weird calling convention and triple leading underscores), and one of the architectures described in Drepper's original TLS white paper, so yes, variant II.