I am working on a baremetal riscv toolchain using LLVM runtime and
LLD linker. Baremetal.cpp provides most of the things needed for such
toolchain. So I have modified it to also handle riscv64/32-unknown-elf
 targets alongside arm-none-eabi.

Currently, targets like riscv64-unknown-elf are handled by RISCVToolChain
which mostly expects a gcc toolchain to be present. If you dont
want the dependency on gcc-toolchain/libgloss or want to use LLD, then
RISCVToolChain is not a good fit.

So in the toolchain selection code, I have made this dependency of
RISCVToolChain on gcc toolchain explicit. It is created if gcc-toolchain
option is present. Otherwise Baremetal toolchain is created. I will be
happy to hear if there is a better way to choose between these two
toolchains.

Reviewed By: jroelofs

Differential Revision: https://reviews.llvm.org/D91442

This will fix remaining failures on gcc-9 buildbot: http://lab.llvm.org:8011/#/builders/101.
gcc-8 and gcc-9 do not support constexpr destructors nor constexpr allocation.

Fix gcc warnings: -Wconversion, -Wpragmas.

Updated the affected scalable_of_scalable tests in sve-gep.ll, as isConstantSplatValue now returns true in DAGCombiner::visitMUL and folds `(mul x, 1) -> x`

Reviewed By: sdesmalen

Differential Revision: https://reviews.llvm.org/D91363

This reverts commit f690986f.

Compile time then and again...

Differential Revision: https://reviews.llvm.org/D91339

Reverted because the compile time impact is still too high.

isKnownViaNonRecursiveReasoning is used twice, we can do it just once.

Differential Revision: https://reviews.llvm.org/D92152

This reverts commit 3d4c0460.

Compile time impact is still high. Need to understand why.

Differential Revision: https://reviews.llvm.org/D92153

We report an error for unknown `DT_PLTREL` values.
This switches the error to warning.

Differential revision: https://reviews.llvm.org/D92087

Previously we tried to using isKnownPredicateAt, but it makes an
extra query to isKnownPredicate, which has negative impact on compile
time. Let's try to use more lightweight isBasicBlockEntryGuardedByCond.

Differential Revision: https://reviews.llvm.org/D92152

This handles cases were the input isn't known to be sign extended.

[RISCV] Add test cases for missed opportunities to use sbsetw/sbclrw/sbinvw when the result isn't known to be sign extended.

If the input isn't sign extended, but the output of the or/xor/and
is used by a sign_inreg we can still use sbsetw/sbclrw/sbinvw.

This reverts commit 14f2ad0e.

Reverting to investigate compile time drop.

Differential Revision: https://reviews.llvm.org/D92152

I recalled Marshall had already made this change. The change is
committed in e3f89a98.

[libc++] [P0966] [C++20] Fix bug PR45368 by correctly implementing P0966: string::reserve should not shrink.

This patch fixes the implementation as well as the tests that didn't actually test the wanted behaviour.
You'll find all the details in the bug report.
It adds as well deprecation warning for reserve() (without argument) and adds a test.

http://wg21.link/P0966R1
https://bugs.llvm.org/show_bug.cgi?id=45368
https://reviews.llvm.org/D54992

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D91778

It's more future-proof to use isGFX10Plus from the start, on the
assumption that future architectures will be based on current
architectures.

Also make use of the existing isGFX9Plus in a few places.

Differential Revision: https://reviews.llvm.org/D92092

Currently, papers and issues are in separate .csv files (that is easier to update), but I can put them inline.Transforming current html tables into rst are done by the script (attached to the patch FYI but I'll remove it before committing).
I'll of course update RST files before committing to match any modifications that may happen in master branch.

This patch moves the status pages in www/ to RST format in docs/.

It also does some other minor changes: fix copyright year and broken comment end, adds substitutions for coherence (and add colors, but that can be removed easily).
It adds as well redirects from old to new status pages.

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D92076

After cf1c774d, Clang seems to generate code
that is more similar to icc/Clang, so we can use the same line numbers for
all compilers in this test.

Fixes https://github.com/clangd/clangd/issues/602

Differential Revision: https://reviews.llvm.org/D92148

Differential Revision: https://reviews.llvm.org/D71126

Needed for a future automatic update to RST.

This should make the builder http://lab.llvm.org:8011/#/builders/101/ happy.
It uses gcc-9 and not Tip-Of-Trunk as its name indicates BTW.
GCC-10 passes all these tests.

Fix gcc warnings: -Wsign-compare, -Wparentheses, -Wpragmas.

Reviewed By: ldionne, #libc, #libc_abi

Differential Revision: https://reviews.llvm.org/D92099

This addresses post review comment for D92018.

The warning was:

```
error: loop variable 'Note' is always a copy because the range of type 'iterator_range<llvm::object::ELFFile<llvm::object::ELFType<llvm::support::big, true> >::Elf_Note_Iterator>' (aka 'iterator_range<Elf_Note_Iterator_Impl<ELFType<(llvm::support::endianness)0U, true> > >') does not return a reference [-Werror,-Wrange-loop-analysis]
      for (const typename ELFT::Note &Note : Obj.notes(S, Err))
```

A piece of code in `isLoopBackedgeGuardedByCond` basically duplicates
the dominators traversal from `isBlockEntryGuardedByCond` called from
`isKnownPredicateAt`, but it's less powerful because it does not give context
to `isImpliedCond`. This patch reuses the `isKnownPredicateAt `function there,
reducing the amount of code duplication and making it more powerful.

Differential Revision: https://reviews.llvm.org/D92152
Reviewed By: skatkov

Use more context to prove contextual facts about the last iteration. It is
only executed when the backedge is taken, so we can use `isLoopBackedgeGuardedByCond`
to make this check.

Differential Revision: https://reviews.llvm.org/D91535
Reviewed By: skatkov

[LegalizerTypes] Add support for scalarizing the operand of an FP_EXTEND when the result type is legal.

LoopLoadElim may end up expanding an AddRec from a loop
which is not the current loop. This loop may not be in simplify
form. We figure it out after the no-return point, so cannot bail
in this case.

AddRec requires simplify form to expand. The only way to ensure
this does not crash is to simplify all loops beforehand.

The issue only exists in new PM. Old PM requests LoopSimplify
required pass and it simplifies all loops before the opt begins.

Differential Revision: https://reviews.llvm.org/D91525
Reviewed By: asbirlea, aeubanks

Differential Revision: https://reviews.llvm.org/D92144

Without this extra flag we can't distingish between stub functions and
functions that happen to have address 0 (relative to __table_base).

Adding this flag bit the base symbol class actually avoids growing the
SymbolUnion struct which would not be true if we added it to the
FunctionSymbol subclass (due to bitbacking).

The previous approach of setting it's table index to zero worked for
normal static relocations but not for `-fPIC` code.

See https://github.com/emscripten-core/emscripten/issues/12819

Differential Revision: https://reviews.llvm.org/D92038

We want to find 'sources = [', but only if it's not the prefix
of 'sources = []' -- we're looking for a non-empty list.

No behavior change.

No behavior change, but maybe a bit clearer.

With this, changes like b534beab can be merged automatically.

This is needed for call hierarchy to be able to find callers of
main-file-only functions.

Differential Revision: https://reviews.llvm.org/D92000

This change gives sparse compiler clients more control over selecting
individual types for the pointers and indices in the sparse storage schemes.
Narrower width obviously results in smaller memory footprints, but the
range should always suffice for the maximum number of entries or index value.

Reviewed By: penpornk

Differential Revision: https://reviews.llvm.org/D92126