summaryrefslogtreecommitdiff
path: root/contrib/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Move all sources from the llvm project into contrib/llvm-project.Dimitry Andric2019-12-202946-1912244/+0
| | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=355940
* Merge commit 241cbf201 from llvm git (by Nemanja Ivanovic):Dimitry Andric2019-12-041-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | [PowerPC] Fix crash in peephole optimization When converting reg+reg shifts to reg+imm rotates, we neglect to consider the CodeGenOnly versions of the 32-bit shift mnemonics. This means we produce a rotate with missing operands which causes a crash. Committing this fix without review since it is non-controversial that the list of mnemonics to consider should include the 64-bit aliases for the exact mnemonics. Fixes PR44183. This should fix "Assertion failed: (idx < size()), function operator[], file /usr/src/contrib/llvm/include/llvm/ADT/SmallVector.h, line 153" when building the graphics/mesa-dri port for the PowerPC64 ELFv2 ABI. Reported by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br> MFC after: 1 month X-MFC-With: r353358 Notes: svn path=/head/; revision=355397
* Merge commit bf996f761 from llvm git (by Simon Atanasyan):Dimitry Andric2019-11-211-1/+3
| | | | | | | | | | | | | | | | | | [mips] Write `AFL_EXT_OCTEONP` flag to the `.MIPS.abiflags` section Differential Revision: https://reviews.llvm.org/D69851 This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite. Requested by: kevans MFC after: 1 month X-MFC-With: r353358 Notes: svn path=/head/; revision=354981
* Merge commit 3718102d4 from llvm git (by Simon Atanasyan):Dimitry Andric2019-11-211-2/+3
| | | | | | | | | | | | | | | | | | [mips] Support `octeon+` CPU in the `.set arch=` directive Differential Revision: https://reviews.llvm.org/D69850 This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite. Requested by: kevans MFC after: 1 month X-MFC-With: r353358 Notes: svn path=/head/; revision=354980
* Merge commit 7bed381ea from llvm git (by Simon Atanasyan):Dimitry Andric2019-11-219-6/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [mips] Implement Octeon+ `saa` and `saad` instructions `saa` and `saad` are 32-bit and 64-bit store atomic add instructions. memory[base] = memory[base] + rt These instructions are available for "Octeon+" CPU. The patch adds support for both instructions to MIPS assembler and diassembler and introduces new CPU type - "octeon+". Next patches will implement `.set arch=octeon+` directive and `AFL_EXT_OCTEONP` ISA extension flag support. Differential Revision: https://reviews.llvm.org/D69849 This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite. Requested by: kevans MFC after: 1 month X-MFC-With: r353358 Notes: svn path=/head/; revision=354979
* Merge commit 5bbb604bb from llvm git (by Craig Topper):Dimitry Andric2019-11-151-7/+20
| | | | | | | | | | | | | | | | | | | [InstCombine] Disable some portions of foldGEPICmp for GEPs that return a vector of pointers. Fix other portions. llvm-svn: 370114 This should fix instances of 'Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /usr/src/contrib/llvm/include/llvm/Support/Casting.h, line 255', when building openjdk8 for aarch64 and armv7. Reported by: jbeich PR: 236566 MFC after: 3 days Notes: svn path=/head/; revision=354724
* llvm: use elf_aux_info to get executable's path, if availableEd Maste2019-11-141-1/+14
| | | | | | | | | Obtained from: LLVM a0a38b81ea MFC with: r354692 Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=354707
* llvm: use AT_EXECPATH from ELF auxiliary vectors for getExecutablePathEd Maste2019-11-131-5/+27
| | | | | | | | | | | | /proc/curproc/file and the KERN_PROC_PATHNAME sysctl may not return the desired path if there are multiple hardlinks to the file. PR: 241932 Tested by: ler Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=354692
* Merge commit f596f4507 from llvm git (by Sam Elliott):Dimitry Andric2019-11-0717-44/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [RISCV] Add Custom Parser for Atomic Memory Operands Summary: GCC Accepts both (reg) and 0(reg) for atomic instruction memory operands. These instructions do not allow for an offset in their encoding, so in the latter case, the 0 is silently dropped. Due to how we have structured the RISCVAsmParser, the easiest way to add support for parsing this offset is to add a custom AsmOperand and parser. This parser drops all the parens, and just keeps the register. This commit also adds a custom printer for these operands, which matches the GCC canonical printer, printing both `(a0)` and `0(a0)` as `(a0)`. Reviewers: asb, lewis-revill Reviewed By: asb Subscribers: s.egerton, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, jfb, PkmX, jocewei, psnobl, benna, Jim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65205 llvm-svn: 367553 Merge commit f596f4507 from llvm git (by Sam Elliott): [RISCV] Add FreeBSD targets Reviewers: asb Reviewed By: asb Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne, emaste, kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57795 Patch by James Clarke (jrtc27) llvm-svn: 367557 Merge commit f596f4507 from llvm git (by Hsiangkai Wang): [DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame. It is necessary to generate fixups in .debug_frame or .eh_frame as relaxation is enabled due to the address delta may be changed after relaxation. There is an opcode with 6-bits data in debug frame encoding. So, we also need 6-bits fixup types. Differential Revision: https://reviews.llvm.org/D58335 llvm-svn: 366524 Merge commit f596f4507 from llvm git (by Hsiangkai Wang): [DebugInfo] Some fields do not need relocations even relax is enabled. In debug frame information, some fields, e.g., Length in CIE/FDE and Offset in FDE are attributes to describe the structure of CIE/FDE. They are not related to the relaxed code. However, these attributes are symbol differences. So, in current design, these attributes will be filled as zero and LLVM generates relocations for them. We only need to generate relocations for symbols in executable sections. So, if the symbols are not located in executable sections, we still evaluate their values under relaxation. Differential Revision: https://reviews.llvm.org/D61584 llvm-svn: 366531 Merge commit f596f4507 from llvm git (by Alex Bradbury): [RISCV] Don't force absolute FK_Data_X fixups to relocs The current behavior of shouldForceRelocation forces relocations for the majority of fixups when relaxation is enabled. This makes sense for fixups which incorporate symbols but is unnecessary for simple data fixups where the fixup target is already resolved to an absolute value. Differential Revision: https://reviews.llvm.org/D63404 Patch by Edward Jones. llvm-svn: 369257 Merge commit f596f4507 from llvm git (by Alex Bradbury): [RISCV] Implement getExprForFDESymbol to ensure RISCV_32_PCREL is used for the FDE location Follow binutils in using RISCV_32_PCREL for the FDE initial location. As explained in the relevant binutils commit <https://github.com/riscv/riscv-binutils-gdb/commit/a6cbf936e3dce68114d28cdf60d510a3f78a6d40>, the ADD/SUB pair of relocations is problematic in the presence of linker relaxation. This patch has the same end goal as D64715 but includes test changes and avoids adding a new global VariantKind to MCExpr.h (preferring RISCVMCExpr VKs like the rest of the RISC-V backend). Differential Revision: https://reviews.llvm.org/D66419 llvm-svn: 369375 This series of merges will permit riscv64 kernels and riscv64sf worlds to build with clang instead of gcc (but still using the bfd linker). Requested by: jhb Obtained from: https://github.com/freebsd/freebsd/compare/master...bsdjhb:riscv_clang MFC after: 1 month X-MFC-With: r353358 Notes: svn path=/head/; revision=354469
* Merge commit 8e34dd941 from llvm git (by Sanjay Patel):Dimitry Andric2019-11-071-3/+5
| | | | | | | | | | | | | | | | | | | [x86] avoid crashing when splitting AVX stores with non-simple type (PR43916) The store splitting transform was assuming a simple type (MVT), but that's not necessarily the case as shown in the test. This should fix 'Assertion failed: (isSimple() && "Expected a SimpleValueType!")' when building the security/openssl111 port targeting a CPU that supports AVX, but not AVX2, such as sandybridge. PR: 241747 MFC after: 1 month X-MFC-With: r353358 Notes: svn path=/head/; revision=354429
* Merge commit 97e362607 from llvm git (by Nemanja Ivanovic):Dimitry Andric2019-11-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | [PowerPC] Do not emit HW loop if the body contains calls to lrint/lround These two intrinsics are lowered to calls so should prevent the formation of CTR loops. In a subsequent patch, we will handle all currently known intrinsics and prevent the formation of HW loops if any unknown intrinsics are encountered. Differential revision: https://reviews.llvm.org/D68841 This should fix an "invalid CRT loop" assertion when building the www/node port for powerpc64. Requested by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br> MFC after: 1 month X-MFC-With: r353358 Notes: svn path=/head/; revision=354339
* Pull in r373338 from upstream llvm trunk (by Simon Pilgrim):Dimitry Andric2019-10-291-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert rL349624 : Let TableGen write output only if it changed, instead of doing so in cmake, attempt 2 Differential Revision: https://reviews.llvm.org/D55842 ----------------- As discussed on PR43385 this is causing Visual Studio msbuilds to perpetually rebuild all tablegen generated files Pull in r373664 from upstream llvm trunk (by Nico Weber): Reland r349624: Let TableGen write output only if it changed, instead of doing so in cmake Move the write-if-changed logic behind a flag and don't pass it with the MSVC generator. msbuild doesn't have a restat optimization, so not doing write-if-change there doesn't have a cost, and it should fix whatever causes PR43385. This should fix the scenario where an incremental build from before r353358 (the clang 9.0.0 upgrade) to r353358 or later fails to update the timestamp of the generated lib/clang/headers/arm_fp16.h header. After such a build, installing world from read-only source and object directories would attempt to generate the header again, leading to "clang-tblgen: error opening arm_fp16.h.d:Read-only file system". Reported by: avg, np PR: 241402 MFC after: 1 month X-MFC-With: r353358 Notes: svn path=/head/; revision=354146
* Pull in r372186 from upstream llvm trunk (by Eli Friedman):Dimitry Andric2019-10-257-21/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ARM] VFPv2 only supports 16 D registers. r361845 changed the way we handle "D16" vs. "D32" targets; there used to be a negative "d16" which removed instructions from the instruction set, and now there's a "d32" feature which adds instructions to the instruction set. This is good, but there was an oversight in the implementation: the behavior of VFPv2 was changed. In particular, the "vfp2" feature was changed to imply "d32". This is wrong: VFPv2 only supports 16 D registers. In practice, this means if you specify -mfpu=vfpv2, the compiler will generate illegal instructions. This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2" and "vfp2sp" so they don't imply "d32". Differential Revision: https://reviews.llvm.org/D67375 Pull in r372187 from upstream clang trunk (by Eli Friedman): [ARM] Update clang for removal of vfp2d16 and vfp2d16sp Matching fix for https://reviews.llvm.org/D67375 (r372186). Differential Revision: https://reviews.llvm.org/D67467 This should fix clang generating invalid opcodes for floating point operations on armv6. Requested by: mmel MFC after: 3 days Notes: svn path=/head/; revision=354097
* Pull in r372606 from upstream llvm trunk (by Sanjay Patel):Dimitry Andric2019-09-232-5/+6
| | | | | | | | | | | | | | | | | [x86] fix assert with horizontal math + broadcast of vector (PR43402) https://bugs.llvm.org/show_bug.cgi?id=43402 This should fix 'Assertion failed: ((HOp.getValueType() == MVT::v2f64 || HOp.getValueType() == MVT::v4f64) && HOp.getValueType() == VT && "Unexpected type for h-op"), function foldShuffleOfHorizOp, file contrib/llvm/lib/Target/X86/X86ISelLowering.cpp, line 33661' when building the devel/llvm90 port with CPUTYPE=haswell. PR: 240759 Notes: svn path=/projects/clang900-import/; revision=352629
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmpDimitry Andric2019-09-194-14/+36
| | | | | | | release 9.0.0 r372316, and update version numbers. Notes: svn path=/projects/clang900-import/; revision=352536
* Revert commit from upstream llvm trunk (by Hans Wennborg):Dimitry Andric2019-09-141-15/+14
| | | | | | | | | | | | | | | | | | Re-commit r357452 (take 3): "SimplifyCFG SinkCommonCodeFromPredecessors: Also sink function calls without used results (PR41259)" Third time's the charm. This was reverted in r363220 due to being suspected of an internal benchmark regression and a test failure, none of which turned out to be caused by this. As reported in https://bugs.llvm.org/show_bug.cgi?id=43269, this causes UNREACHABLE errors when compiling if_malo_pci.c for arm and aarch64. Notes: svn path=/projects/clang900-import/; revision=352318
* Merge ^/head r351732 through r352104.Dimitry Andric2019-09-091-2/+8
|\ | | | | | | Notes: svn path=/projects/clang900-import/; revision=352105
| * Pull in r371111 from upstream llvm trunk (by Eli Friedman):Dimitry Andric2019-09-061-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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 Notes: svn path=/head/; revision=351938
* | Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmpDimitry Andric2019-09-077-22/+56
| | | | | | | | | | | | | | release_90 branch r371301, and update version numbers. Notes: svn path=/projects/clang900-import/; revision=352010
* | Pull in r370426 from upstream llvm trunk (by Fāng-ruì Sòng):Dimitry Andric2019-09-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [PPC32] Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO Unlike ppc64, which has ADDISgotTprelHA+LDgotTprelL pairs, ppc32 just uses LDgotTprelL32, so it does not make lots of sense to use _LO without a paired _HA. Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO to match GCC, and get better linker relocation check. Note, R_PPC_GOT_TPREL16_{HA,LO} don't have good linker support: (a) lld does not support R_PPC_GOT_TPREL16_{HA,LO}. (b) Top of tree ld.bfd does not support R_PPC_GOT_REL16_HA Initial-Exec -> Local-Exec relaxation: // a.o addis 3, 3, tsd_tls@got@tprel@ha lwz 3, tsd_tls@got@tprel@l(3) add 3, 3, tsd_tls@tls // b.o .section .tdata,"awT"; .globl tsd_tls; tsd_tls: // ld/ld-new a.o b.o internal error, aborting at ../../bfd/elf32-ppc.c:7952 in ppc_elf_relocate_section Reviewed By: adalava Differential Revision: https://reviews.llvm.org/D66925 This allows use of LLD for linking 32-bit static binaries on FreeBSD/powerpc. Submitted by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br> Notes: svn path=/projects/clang900-import/; revision=352009
* | Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmpDimitry Andric2019-09-0214-34/+118
| | | | | | | | | | | | | | release_90 branch r370514, and update version numbers. Notes: svn path=/projects/clang900-import/; revision=351722
* | Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb, and openmpDimitry Andric2019-09-0240-287/+753
| | | | | | | | | | | | | | release_90 branch r369369, and update version numbers. Notes: svn path=/projects/clang900-import/; revision=351708
* | Merge llvm trunk r366426, resolve conflicts, and update FREEBSD-Xlist.Dimitry Andric2019-08-212929-75456/+171191
|/ | | | Notes: svn path=/projects/clang900-import/; revision=351344
* Pull in r366369 from upstream llvm trunk (by Francis Visoiu Mistrih):Dimitry Andric2019-07-262-13/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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 Notes: svn path=/head/; revision=350362
* Pull in r360968 from upstream llvm trunk (by Philip Reames):Dimitry Andric2019-07-012-173/+266
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clarify comments on helpers used by LFTR [NFC] I'm slowly wrapping my head around this code, and am making comment improvements where I can. Pull in r360972 from upstream llvm trunk (by Philip Reames): [LFTR] Factor out a helper function for readability purpose [NFC] Pull in r360976 from upstream llvm trunk (by Philip Reames): [IndVars] Don't reimplement Loop::isLoopInvariant [NFC] Using dominance vs a set membership check is indistinguishable from a compile time perspective, and the two queries return equivelent results. Simplify code by using the existing function. Pull in r360978 from upstream llvm trunk (by Philip Reames): [LFTR] Strengthen assertions in genLoopLimit [NFCI] Pull in r362292 from upstream llvm trunk (by Nikita Popov): [IndVarSimplify] Fixup nowrap flags during LFTR (PR31181) Fix for https://bugs.llvm.org/show_bug.cgi?id=31181 and partial fix for LFTR poison handling issues in general. When LFTR moves a condition from pre-inc to post-inc, it may now depend on value that is poison due to nowrap flags. To avoid this, we clear any nowrap flag that SCEV cannot prove for the post-inc addrec. Additionally, LFTR may switch to a different IV that is dynamically dead and as such may be arbitrarily poison. This patch will correct nowrap flags in some but not all cases where this happens. This is related to the adoption of IR nowrap flags for the pre-inc addrec. (See some of the switch_to_different_iv tests, where flags are not dropped or insufficiently dropped.) Finally, there are likely similar issues with the handling of GEP inbounds, but we don't have a test case for this yet. Differential Revision: https://reviews.llvm.org/D60935 Pull in r362971 from upstream llvm trunk (by Philip Reames): Prepare for multi-exit LFTR [NFC] This change does the plumbing to wire an ExitingBB parameter through the LFTR implementation, and reorganizes the code to work in terms of a set of individual loop exits. Most of it is fairly obvious, but there's one key complexity which makes it worthy of consideration. The actual multi-exit LFTR patch is in D62625 for context. Specifically, it turns out the existing code uses the backedge taken count from before a IV is widened. Oddly, we can end up with a different (more expensive, but semantically equivelent) BE count for the loop when requerying after widening. For the nestedIV example from elim-extend, we end up with the following BE counts: BEFORE: (-2 + (-1 * %innercount) + %limit) AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>) This is the only test in tree which seems sensitive to this difference. The actual result of using the wider BETC on this example is that we actually produce slightly better code. :) In review, we decided to accept that test change. This patch is structured to preserve the old behavior, but a separate change will immediate follow with the behavior change. (I wanted it separate for problem attribution purposes.) Differential Revision: https://reviews.llvm.org/D62880 Pull in r362975 from upstream llvm trunk (by Philip Reames): [LFTR] Use recomputed BE count This was discussed as part of D62880. The basic thought is that computing BE taken count after widening should produce (on average) an equally good backedge taken count as the one before widening. Since there's only one test in the suite which is impacted by this change, and it's essentially equivelent codegen, that seems to be a reasonable assertion. This change was separated from r362971 so that if this turns out to be problematic, the triggering piece is obvious and easily revertable. For the nestedIV example from elim-extend.ll, we end up with the following BE counts: BEFORE: (-2 + (-1 * %innercount) + %limit) AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>) Note that before is an i32 type, and the after is an i64. Truncating the i64 produces the i32. Pull in r362980 from upstream llvm trunk (by Philip Reames): Factor out a helper function for readability and reuse in a future patch [NFC] Pull in r363613 from upstream llvm trunk (by Philip Reames): Fix a bug w/inbounds invalidation in LFTR (recommit) Recommit r363289 with a bug fix for crash identified in pr42279. Issue was that a loop exit test does not have to be an icmp, leading to a null dereference crash when new logic was exercised for that case. Test case previously committed in r363601. Original commit comment follows: This contains fixes for two cases where we might invalidate inbounds and leave it stale in the IR (a miscompile). Case 1 is when switching to an IV with no dynamically live uses, and case 2 is when doing pre-to-post conversion on the same pointer type IV. The basic scheme used is to prove that using the given IV (pre or post increment forms) would have to already trigger UB on the path to the test we're modifying. As such, our potential UB triggering use does not change the semantics of the original program. As was pointed out in the review thread by Nikita, this is defending against a separate issue from the hasConcreteDef case. This is about poison, that's about undef. Unfortunately, the two are different, see Nikita's comment for a fuller explanation, he explains it well. (Note: I'm going to address Nikita's last style comment in a separate commit just to minimize chance of subtle bugs being introduced due to typos.) Differential Revision: https://reviews.llvm.org/D62939 Pull in r363875 from upstream llvm trunk (by Philip Reames): [LFTR] Rename variable to minimize confusion [NFC] (Recommit of r363293 which was reverted when a dependent patch was.) As pointed out by Nikita in D62625, BackedgeTakenCount is generally used to refer to the backedge taken count of the loop. A conditional backedge taken count - one which only applies if a particular exit is taken - is called a ExitCount in SCEV code, so be consistent here. Pull in r363877 from upstream llvm trunk (by Philip Reames): [LFTR] Stylistic cleanup as suggested in last review comment of D62939 [NFC] (Resumbit of r363292 which was reverted along w/an earlier patch) Pull in r364346 from upstream llvm trunk (by Philip Reames): [LFTR] Adjust debug output to include extensions (if any) Pull in r364693 from upstream llvm trunk (by Philip Reames): [IndVars] Remove a bit of manual constant folding [NFC] SCEV is more than capable of folding (add x, trunc(0)) to x. Pull in r364709 from upstream llvm trunk (by Nikita Popov): [LFTR] Fix post-inc pointer IV with truncated exit count (PR41998) Fixes https://bugs.llvm.org/show_bug.cgi?id=41998. Usually when we have a truncated exit count we'll truncate the IV when comparing against the limit, in which case exit count overflow in post-inc form doesn't matter. However, for pointer IVs we don't do that, so we have to be careful about incrementing the IV in the wide type. I'm fixing this by removing the IVCount variable (which was ExitCount or ExitCount+1) and replacing it with a UsePostInc flag, and then moving the actual limit adjustment to the individual cases (which are: pointer IV where we add to the wide type, integer IV where we add to the narrow type, and constant integer IV where we add to the wide type). Differential Revision: https://reviews.llvm.org/D63686 Together, these should fix a hang when building the textproc/htmldoc port, due to an incorrect loop optimization. PR: 237515 MFC after: 1 week Notes: svn path=/head/; revision=349583
* powerpc: Transition to Secure-PLT, like most other OSs (Toolchain part)Justin Hibbits2019-06-251-1/+2
| | | | | | | | | | | | | | | | Summary: Toolchain follow-up to r349350. LLVM patches will be submitted upstream for 9.0 as well. The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it cannot determine for certain that it needs Secure-PLT, and some binaries do not compile in such a way to make it know to use Secure-PLT. Reviewed By: nwhitehorn, bdragon, pfg Differential Revision: https://reviews.freebsd.org/D20598 Notes: svn path=/head/; revision=349351
* Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++,Dimitry Andric2019-06-1232-176/+216
| | | | | | | | | | | libunwind and openmp to the upstream release_80 branch r363030 (effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a week or so. MFC after: 2 weeks Notes: svn path=/head/; revision=349004
* Pull in r361696 from upstream llvm trunk (by Sanjay Patel):Dimitry Andric2019-05-261-6/+4
| | | | | | | | | | | | | | | | | | | | | [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 <marklmi26-fbsd@yahoo.com> PR: 238082 MFC after: 3 days Notes: svn path=/head/; revision=348288
* Pull in r360099 from upstream llvm trunk (by Eli Friedman):Dimitry Andric2019-05-081-26/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ARM] Glue register copies to tail calls. This generally follows what other targets do. I don't completely understand why the special case for tail calls existed in the first place; even when the code was committed in r105413, call lowering didn't work in the way described in the comments. Stack protector lowering breaks if the register copies are not glued to a tail call: we have to insert the stack protector check before the tail call, and we choose the location based on the assumption that all physical register dependencies of a tail call are adjacent to the tail call. (See FindSplitPointForStackProtector.) This is sort of fragile, but I don't see any reason to break that assumption. I'm guessing nobody has seen this before just because it's hard to convince the scheduler to actually schedule the code in a way that breaks; even without the glue, the only computation that could actually be scheduled after the register copies is the computation of the call address, and the scheduler usually prefers to schedule that before the copies anyway. Fixes https://bugs.llvm.org/show_bug.cgi?id=41417 Differential Revision: https://reviews.llvm.org/D60427 This should fix several instances of "Bad machine code: Using an undefined physical register", when compiling ports such as multimedia/vlc, audio/alsa-lib and devel/avro-c for armv6, with -fstack-protector-strong. Reported by: jbeich PR: 237074, 237783, 237784 MFC after: 3 days Notes: svn path=/head/; revision=347243
* Pull in r356809 from upstream llvm trunk (by Eli Friedman):Dimitry Andric2019-03-231-1/+9
| | | | | | | | | | | | | | | | | | | | | | | [ARM] Don't form "ands" when it isn't scheduled correctly. In r322972/r323136, the iteration here was changed to catch cases at the beginning of a basic block... but we accidentally deleted an important safety check. Restore that check to the way it was. Fixes https://bugs.llvm.org/show_bug.cgi?id=41116 Differential Revision: https://reviews.llvm.org/D59680 This should fix "Assertion failed: (LiveCPSR && "CPSR liveness tracking is wrong!"), function UpdateCPSRUse" errors when building the devel/xwpe port for armv7. PR: 236062, 236568 MFC after: 1 month X-MFC-With: r344779 Notes: svn path=/head/; revision=345449
* Revert r308867 (which was originally committed in the clang390-importDimitry Andric2019-03-121-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | project branch): Work around LLVM PR30879, which is about a bad interaction between X86 Call Frame Optimization on i386 and libunwind, by disallowing the optimization for i386-freebsd12. This should fix some instances of broken exception handling when frame pointers are omitted, in particular some unittests run during the build of editors/libreoffice. This hack will be removed as soon as upstream has implemented a more permanent fix for this problem. And indeed, after r345018 and r345019, which updated LLVM libunwind to the most recent version, the above workaround is no longer needed. The upstream commit which fixed this is: https://llvm.org/viewvc/llvm-project?view=revision&revision=292723 Specifically, 32 bit (i386-freebsd) executables optimized with omitted frame pointers and Call Frame Optimization should now behave correctly when a C++ exception is thrown, and the stack is unwound. Upstream PR: https://llvm.org/bugs/show_bug.cgi?id=30879 PR: 236062 MFC after: 1 month X-MFC-With: r344779 Notes: svn path=/head/; revision=345073
* Pull in r355854 from upstream llvm trunk (by Jonas Paulsson):Dimitry Andric2019-03-111-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | [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 Notes: svn path=/head/; revision=345021
* Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branchDimitry Andric2019-03-045-18/+22
| | | | | | | r355313, resolve conflicts, and bump version numbers. Notes: svn path=/projects/clang800-import/; revision=344774
* Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branchDimitry Andric2019-02-253-95/+148
| | | | | | | r354799, resolve conflicts, and bump version numbers. Notes: svn path=/projects/clang800-import/; revision=344548
* Merge ^/head r344178 through r344512.Dimitry Andric2019-02-251-5/+13
|\ | | | | | | Notes: svn path=/projects/clang800-import/; revision=344513
| * Pull in r354756 from upstream llvm trunk (by Craig Topper):Dimitry Andric2019-02-241-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [X86] Fix tls variable lowering issue with large code model Summary: The problem here is the lowering for tls variable. Below is the DAG for the code. SelectionDAG has 11 nodes: t0: ch = EntryToken t8: i64,ch = load<(load 8 from `i8 addrspace(257)* null`, addrspace 257)> t0, Constant:i64<0>, undef:i64 t10: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=10] t11: i64,ch = load<(load 8 from got)> t0, t10, undef:i64 t12: i64 = add t8, t11 t4: i32,ch = load<(dereferenceable load 4 from @x)> t0, t12, undef:i64 t6: ch = CopyToReg t0, Register:i32 %0, t4 And when mcmodel is large, below instruction can NOT be folded. t10: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=10] t11: i64,ch = load<(load 8 from got)> t0, t10, undef:i64 So "t11: i64,ch = load<(load 8 from got)> t0, t10, undef:i64" is lowered to " Morphed node: t11: i64,ch = MOV64rm<Mem:(load 8 from got)> t10, TargetConstant:i8<1>, Register:i64 $noreg, TargetConstant:i32<0>, Register:i32 $noreg, t0" When llvm start to lower "t10: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=10]", it fails. The patch is to fold the load and X86ISD::WrapperRIP. Fixes PR26906 Patch by LuoYuanke Reviewers: craig.topper, rnk, annita.zhang, wxiao3 Reviewed By: rnk Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58336 This should fix "fatal error: error in backend: Cannot select" messages when compiling <ctype.h> functions using -mcmodel=large. Reported by: phk PR: 233143 MFC after: 3 days Notes: svn path=/head/; revision=344503
* | Merge ^/head r343956 through r344177.Dimitry Andric2019-02-151-6/+12
|\| | | | | | | Notes: svn path=/projects/clang800-import/; revision=344178
| * Pull in r353907 from upstream llvm trunk (by Reid Kleckner):Dimitry Andric2019-02-131-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [MC] Make symbol version errors non-fatal We stil don't have a source location, which is pretty lame, but at least we won't tell the user to file a clang bug report anymore. Fixes PR40712 This will make errors for symbols with @@ versions that are not defined non-fatal. For example: void f(void) { __asm__(".symver foo,bar@@baz"); } will now result in: error: versioned symbol bar@@baz must be defined instead of clang crashing with a diagnostic report. PR: 234671 Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=40712 MFC after: 3 days Notes: svn path=/head/; revision=344112
| * Pull in r339734 from upstream llvm trunk (by Eli Friedman):Dimitry Andric2019-02-125-7/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly. Intentionally excluding nodes from the DAGCombine worklist is likely to lead to weird optimizations and infinite loops, so it's generally a bad idea. To avoid the infinite loops, fix DAGCombine to use the isDesirableToCommuteWithShift target hook before performing the transforms in question, and implement the target hook in the ARM backend disable the transforms in question. Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don't have a reduced testcase for that bug. But we should have sufficient test coverage for PerformSHLSimplify given that we're not playing weird tricks with the worklist. I can try to bugpoint it if necessary, though.) Differential Revision: https://reviews.llvm.org/D50667 This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c (which exists now only in the stable/11 branch) for arm. Notes: svn path=/head/; revision=344056
| * Pull in r352607 from upstream llvm trunk (by Craig Topper):Dimitry Andric2019-02-084-27/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [X86] Add FPSW as a Def on some FP instructions that were missing it. Pull in r353141 from upstream llvm trunk (by Craig Topper): [X86] Connect the default fpsr and dirflag clobbers in inline assembly to the registers we have defined for them. Summary: We don't currently map these constraints to physical register numbers so they don't make it to the MachineIR representation of inline assembly. This could have problems for proper dependency tracking in the machine schedulers though I don't have a test case that shows that. Reviewers: rnk Reviewed By: rnk Subscribers: eraman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57641 Pull in r353489 from upstream llvm trunk (by Craig Topper): [X86] Add FPCW as a register and start using it as an implicit use on floating point instructions. Summary: FPCW contains the rounding mode control which we manipulate to implement fp to integer conversion by changing the roudning mode, storing the value to the stack, and then changing the rounding mode back. Because we didn't model FPCW and its dependency chain, other instructions could be scheduled into the middle of the sequence. This patch introduces the register and adds it as an implciit def of FLDCW and implicit use of the FP binary arithmetic instructions and store instructions. There are more instructions that need to be updated, but this is a good start. I believe this fixes at least the reduced test case from PR40529. Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor Subscribers: dim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57735 These should fix a problem in clang 7.0 where it would sometimes emit long double floating point instructions in a slightly wrong order, leading to failures in our libm tests. In particular, the cbrt_test test case 'cbrtl_powl' and the trig_test test case 'reduction'. Also bump __FreeBSD_cc_version, to be able to detect this in our test suite. Reported by: lwhsu PR: 234040 Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=40206 MFC after: 1 week Notes: svn path=/head/; revision=343916
* | Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branchDimitry Andric2019-02-1519-243/+360
| | | | | | | | | | | | | | r354130, resolve conflicts, and bump version numbers. Notes: svn path=/projects/clang800-import/; revision=344177
* | Pull in r352607 from upstream llvm trunk (by Craig Topper):Dimitry Andric2019-02-1010-105/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [X86] Add FPSW as a Def on some FP instructions that were missing it. Pull in r352608 from upstream llvm trunk (by Craig Topper): [X86] Remove a couple places where we unnecessarily pass 0 to the EmitPriority of some FP instruction aliases. NFC As far as I can tell we already won't emit these aliases due to an operand count check in the tablegen code. Removing these because I couldn't make sense of the inconsistency between fadd and fmul from reading the code. I checked the AsmMatcher and AsmWriter files before and after this change and there were no differences. Pull in r353015 from upstream llvm trunk (by Craig Topper): [X86] Print %st(0) as %st when its implicit to the instruction. Continue printing it as %st(0) when its encoded in the instruction. This is a step back from the change I made in r352985. This appears to be more consistent with gcc and objdump behavior. Pull in r353061 from upstream llvm trunk (by Craig Topper): [X86] Print all register forms of x87 fadd/fsub/fdiv/fmul as having two arguments where on is %st. All of these instructions consume one encoded register and the other register is %st. They either write the result to %st or the encoded register. Previously we printed both arguments when the encoded register was written. And we printed one argument when the result was written to %st. For the stack popping forms the encoded register is always the destination and we didn't print both operands. This was inconsistent with gcc and objdump and just makes the output assembly code harder to read. This patch changes things to always print both operands making us consistent with gcc and objdump. The parser should still be able to handle the single register forms just as it did before. This also matches the GNU assembler behavior. Pull in r353141 from upstream llvm trunk (by Craig Topper): [X86] Connect the default fpsr and dirflag clobbers in inline assembly to the registers we have defined for them. Summary: We don't currently map these constraints to physical register numbers so they don't make it to the MachineIR representation of inline assembly. This could have problems for proper dependency tracking in the machine schedulers though I don't have a test case that shows that. Reviewers: rnk Reviewed By: rnk Subscribers: eraman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57641 Pull in r353489 from upstream llvm trunk (by Craig Topper): [X86] Add FPCW as a register and start using it as an implicit use on floating point instructions. Summary: FPCW contains the rounding mode control which we manipulate to implement fp to integer conversion by changing the roudning mode, storing the value to the stack, and then changing the rounding mode back. Because we didn't model FPCW and its dependency chain, other instructions could be scheduled into the middle of the sequence. This patch introduces the register and adds it as an implciit def of FLDCW and implicit use of the FP binary arithmetic instructions and store instructions. There are more instructions that need to be updated, but this is a good start. I believe this fixes at least the reduced test case from PR40529. Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor Subscribers: dim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57735 These should fix a problem in clang 7.0 where it would sometimes emit long double floating point instructions in a slightly wrong order, leading to failures in our libm tests. In particular, the cbrt_test test case 'cbrtl_powl' and the trig_test test case 'reduction'. Reported by: lwhsu PR: 234040 Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=40206 Notes: svn path=/projects/clang800-import/; revision=343955
* | Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branchDimitry Andric2019-02-0527-100/+353
| | | | | | | | | | | | | | r353167, resolve conflicts, and bump version numbers. Notes: svn path=/projects/clang800-import/; revision=343806
* | Reduce diff against upstream.Dimitry Andric2019-01-221-1/+0
| | | | | | | | Notes: svn path=/projects/clang800-import/; revision=343321
* | Merge llvm release_80 branch r351543, and resolve conflicts.Dimitry Andric2019-01-2230-87/+397
| | | | | | | | Notes: svn path=/projects/clang800-import/; revision=343313
* | Merge llvm trunk r351319, resolve conflicts, and update FREEBSD-Xlist.Dimitry Andric2019-01-201564-69595/+143993
|/ | | | Notes: svn path=/projects/clang800-import/; revision=343210
* Pull in r342863 from upstream llvm trunk (by Hans Wennborg):Dimitry Andric2018-12-291-2/+0
| | | | | | | | | | | Remove debug printf leftover from r342397 PR: 234480 MFC after: 6 weeks X-MFC-With: r341825 Notes: svn path=/head/; revision=342593
* Pull in r342397 from upstream llvm trunk (by Amara Emerson):Dimitry Andric2018-12-291-1/+10
| | | | | | | | | | | | | | | | | | | | | | Revert "Revert r342183 "[DAGCombine] Fix crash when store merging created an extract_subvector with invalid index."" Fixed the assertion failure. Differential Revision: https://reviews.llvm.org/D51831 This fixes 'Assertion failed: ((VT.getVectorNumElements() + N2C->getZExtValue() <= N1.getValueType().getVectorNumElements()) && "Extract subvector overflow!"), function getNode' when building the multimedia/aom port (with AVX2 enabled). Reported by: jbeich PR: 234480 MFC after: 6 weeks X-MFC-With: r341825 Notes: svn path=/head/; revision=342592
* Merge llvm, clang, lld, lldb, compiler-rt and libc++ release_70 branchDimitry Andric2018-12-0925-149/+347
| | | | | | | | | | r348686 (effectively 7.0.1 rc3), resolve conflicts, and bump version numbers. PR: 230240, 230355 Notes: svn path=/projects/clang700-import/; revision=341763
* Merge llvm, clang, lld, lldb, compiler-rt and libc++ release_70 branchDimitry Andric2018-11-048-62/+116
| | | | | | | | | | r346007 (effectively 7.0.1 rc2), resolve conflicts, and bump version numbers. PR: 230240, 230355 Notes: svn path=/projects/clang700-import/; revision=340125
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-31 22:48:13 +0000