src-test/contrib/llvm/lib/CodeGen, branch main

Move all sources from the llvm project into contrib/llvm-project.

2019-12-20T19:53:05Z

This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together. Updating the vendor area to match this layout is next.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmp

2019-09-19T19:25:01Z

release 9.0.0 r372316, and update version numbers.

Merge ^/head r351732 through r352104.

2019-09-09T19:58:46Z

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmp

2019-09-07T12:31:36Z

release_90 branch r371301, and update version numbers.

Pull in r371111 from upstream llvm trunk (by Eli Friedman):

2019-09-06T16:06:37Z

[IfConversion] Fix diamond conversion with unanalyzable branches. The code was incorrectly counting the number of identical instructions, and therefore tried to predicate an instruction which should not have been predicated. This could have various effects: a compiler crash, an assembler failure, a miscompile, or just generating an extra, unnecessary instruction. Instead of depending on TargetInstrInfo::removeBranch, which only works on analyzable branches, just remove all branch instructions. Fixes https://bugs.llvm.org/show_bug.cgi?id=43121 and https://bugs.llvm.org/show_bug.cgi?id=41121 . Differential Revision: https://reviews.llvm.org/D67203 This should fix "Unable to predicate BX killed renamable $r0" errors when building the lang/spidermonkey170 and lang/spidermonkey38 ports for armv7 and armv6. PR: 236567 MFC after: 3 days

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmp

2019-09-02T17:32:57Z

release_90 branch r369369, and update version numbers.

Merge llvm trunk r366426, resolve conflicts, and update FREEBSD-Xlist.

2019-08-21T18:13:02Z

Pull in r366369 from upstream llvm trunk (by Francis Visoiu Mistrih):

2019-07-26T18:49:20Z

[CodeGen][NFC] Simplify checks for stack protector index checking Use `hasStackProtectorIndex()` instead of `getStackProtectorIndex() >= 0`. Pull in r366371 from upstream llvm trunk (by Francis Visoiu Mistrih): [PEI] Don't re-allocate a pre-allocated stack protector slot The LocalStackSlotPass pre-allocates a stack protector and makes sure that it comes before the local variables on the stack. We need to make sure that later during PEI we don't re-allocate a new stack protector slot. If that happens, the new stack protector slot will end up being **after** the local variables that it should be protecting. Therefore, we would have two slots assigned for two different stack protectors, one at the top of the stack, and one at the bottom. Since PEI will overwrite the assigned slot for the stack protector, the load that is used to compare the value of the stack protector will use the slot assigned by PEI, which is wrong. For this, we need to check if the object is pre-allocated, and re-use that pre-allocated slot. Differential Revision: https://reviews.llvm.org/D64757 Pull in r367068 from upstream llvm trunk (by Francis Visoiu Mistrih): [CodeGen] Don't resolve the stack protector frame accesses until PEI Currently, stack protector loads and stores are resolved during LocalStackSlotAllocation (if the pass needs to run). When this is the case, the base register assigned to the frame access is going to be one of the vregs created during LocalStackSlotAllocation. This means that we are keeping a pointer to the stack protector slot, and we're using this pointer to load and store to it. In case register pressure goes up, we may end up spilling this pointer to the stack, which can be a security concern. Instead, leave it to PEI to resolve the frame accesses. In order to do that, we make all stack protector accesses go through frame index operands, then PEI will resolve this using an offset from sp/fp/bp. Differential Revision: https://reviews.llvm.org/D64759 Together, these fix a issue where the stack protection feature in LLVM's ARM backend can be rendered ineffective when the stack protector slot is re-allocated so that it appears after the local variables that it is meant to protect, leaving the function potentially vulnerable to a stack-based buffer overflow. Reported by: andrew Security: https://kb.cert.org/vuls/id/129209/ MFC after: 3 days

Pull in r361696 from upstream llvm trunk (by Sanjay Patel):

2019-05-26T15:44:58Z

[SelectionDAG] soften assertion when legalizing narrow vector FP ops The test based on PR42010: https://bugs.llvm.org/show_bug.cgi?id=42010 ...may show an inaccuracy for PPC's target defs, but we should not be so aggressive with an assert here. There's no telling what out-of-tree targets look like. This fixes an assertion when building the graphics/mesa-dri port for PowerPC64. Reported by: Mark Millard PR: 238082 MFC after: 3 days

Pull in r355854 from upstream llvm trunk (by Jonas Paulsson):

2019-03-11T19:15:57Z

[RegAlloc] Avoid compile time regression with multiple copy hints. As a fix for https://bugs.llvm.org/show_bug.cgi?id=40986 ("excessive compile time building opencollada"), this patch makes sure that no phys reg is hinted more than once from getRegAllocationHints(). This handles the case were many virtual registers are assigned to the same physreg. The previous compile time fix (r343686) in weightCalcHelper() only made sure that physical/virtual registers are passed no more than once to addRegAllocationHint(). Review: Dimitry Andric, Quentin Colombet https://reviews.llvm.org/D59201 This should fix a hang when compiling certain generated .cpp files in the graphics/opencollada port. PR: 236313 MFC after: 1 month X-MFC-With: r344779