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
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
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
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
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
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
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
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
same type in multiple base classes.
Not even if the type is introduced by distinct declarations (for
example, two typedef declarations, or a typedef and a class definition).
Define ConstantData::PoisonValue.
Add support for poison value to LLLexer/LLParser/BitcodeReader/BitcodeWriter.
Add support for poison value to llvm-c interface.
Add support for poison value to OCaml binding.
Add m_Poison in PatternMatch.
Differential Revision: https://reviews.llvm.org/D71126
This is partly in preparation for an upcoming change that can change the
order in which DeclContext lookup results are presented.
In passing, fix some obvious errors where name lookup's notion of a
"static member function" missed static member function templates, and
where its notion of "same set of declarations" was confused by the same
declarations appearing in a different order.
In https://reviews.llvm.org/D89072 I added static const data members
to the debug subsection for globals. It skipped emitting an S_CONSTANT if it
didn't have a value, which meant the subsection could be empty.
This patch fixes the empty subsection issue.
Differential Revision: https://reviews.llvm.org/D92049
Revert "[compiler-rt] [builtins] Support conversion between fp16 and fp128" & dependency
Revert "[compiler-rt] [builtins] Use _Float16 on extendhfsf2, truncdfhf2 __truncsfhf2 if available"
This reverts commit 7a94829881.
This reverts commit 1fb91fcf9c.
Start with an assumption that FMA is faster than Fmul+FAdd. If thats not true
on some particular implementation we can add a tuning parameter in the future.
I've update the fmuladd test cases and added new test cases for fast math flag
based contraction.
Differential Revision: https://reviews.llvm.org/D91987
We currently don't match this which limits the effectiveness of D91120 until
InstCombine starts canonicalizing to llvm.abs. This should be easy to remove
if/when we remove the SPF_ABS handling.
Differential Revision: https://reviews.llvm.org/D92118
Hafiz Abid Qadeer