summaryrefslogtreecommitdiff
path: root/contrib/llvm-project
Commit message (Collapse)AuthorAgeFilesLines
* Merge commit b8ebc11f0 from llvm git (by Sanjay Patel):Dimitry Andric2020-03-181-7/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [EarlyCSE] avoid crashing when detecting min/max/abs patterns (PR41083) As discussed in PR41083: https://bugs.llvm.org/show_bug.cgi?id=41083 ...we can assert/crash in EarlyCSE using the current hashing scheme and instructions with flags. ValueTracking's matchSelectPattern() may rely on overflow (nsw, etc) or other flags when detecting patterns such as min/max/abs composed of compare+select. But the value numbering / hashing mechanism used by EarlyCSE intersects those flags to allow more CSE. Several alternatives to solve this are discussed in the bug report. This patch avoids the issue by doing simple matching of min/max/abs patterns that never requires instruction flags. We give up some CSE power because of that, but that is not expected to result in much actual performance difference because InstCombine will canonicalize these patterns when possible. It even has this comment for abs/nabs: /// Canonicalize all these variants to 1 pattern. /// This makes CSE more likely. (And this patch adds PhaseOrdering tests to verify that the expected transforms are still happening in the standard optimization pipelines. I left this code to use ValueTracking's "flavor" enum values, so we don't have to change the callers' code. If we decide to go back to using the ValueTracking call (by changing the hashing algorithm instead), it should be obvious how to replace this chunk. Differential Revision: https://reviews.llvm.org/D74285 This fixes an assertion when building the math/gsl port on PowerPC64. Requested by: pkubja MFC after: 6 weeks X-MFC-With: 358851 Notes: svn path=/head/; revision=359086
* Merge commit 315f8a55f from llvm git (by Fangrui Song):Dimitry Andric2020-03-182-4/+9
| | | | | | | | | | | | | | | | | | | | | | [ELF][PPC32] Don't report "relocation refers to a discarded section" for .got2 Similar to D63182 [ELF][PPC64] Don't report "relocation refers to a discarded section" for .toc Reviewed By: Bdragon28 Differential Revision: https://reviews.llvm.org/D75419 This is needed to fix compile errors when building for ppc32/lld10. Requested by: bdragon MFC after: 6 weeks X-MFC-With: 358851 Differential Revision: https://reviews.freebsd.org/D24110 Notes: svn path=/head/; revision=359085
* Merge commit 00925aadb from llvm git (by Fangrui Song):Dimitry Andric2020-03-185-18/+33
| | | | | | | | | | | | | | | | | | [ELF][PPC32] Fix canonical PLTs when the order does not match the PLT order Reviewed By: Bdragon28 Differential Revision: https://reviews.llvm.org/D75394 This is needed to fix miscompiled canonical PLTs on ppc32/lld10. Requested by: bdragon MFC after: 6 weeks X-MFC-With: 358851 Differential Revision: https://reviews.freebsd.org/D24109 Notes: svn path=/head/; revision=359084
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2020-03-1818-45/+258
| | | | | | | | | | | llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real Soon Now. PR: 244251 MFC after: 6 weeks Notes: svn path=/head/; revision=359082
* Merge ^/vendor/llvm-project/release-10.x up to its last change (upstreamDimitry Andric2020-03-0533-133/+162
| | | | | | | commit llvmorg-10.0.0-rc3-1-gc290cb61fdc), and bump versions. Notes: svn path=/projects/clang1000-import/; revision=358682
* Revert r357259, after the merge from head which added linker scripts forDimitry Andric2020-03-052-27/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | stand/i386 boot: Revert upstream lld r371957 (git commit 06bb7dfbd) by Fangrui Song: [ELF] Map the ELF header at imageBase If there is no readonly section, we map: * The ELF header at imageBase+maxPageSize * Program headers at imageBase+maxPageSize+sizeof(Ehdr) * The first section .text at imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers) Due to the interaction between Writer<ELFT>::fixSectionAlignments and LinkerScript::allocateHeaders, `alignDown(p_vaddr(R PT_LOAD)) = alignDown(p_vaddr(RX PT_LOAD))`. The RX PT_LOAD will override the R PT_LOAD at runtime, which is not ideal: ``` // PHDR at 0x401034, should be 0x400034 PHDR 0x000034 0x00401034 0x00401034 0x000a0 0x000a0 R 0x4 // R PT_LOAD contains just Ehdr and program headers. // At 0x401000, should be 0x400000 LOAD 0x000000 0x00401000 0x00401000 0x000d4 0x000d4 R 0x1000 LOAD 0x0000d4 0x004010d4 0x004010d4 0x00001 0x00001 R E 0x1000 ``` * createPhdrs allocates the headers to the R PT_LOAD. * fixSectionAlignments assigns `imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers)` (formula: `alignTo(dot, maxPageSize) + dot % config->maxPageSize`) to addrExpr of .text * allocateHeaders computes the minimum address among SHF_ALLOC sections, i.e. addr(.text) * allocateHeaders sets address of ELF header to `addr(.text)-sizeof(Ehdr)-sizeof(program headers) = imageBase+maxPageSize` The main observation is that when the SECTIONS command is not used, we don't have to call allocateHeaders. This requires an assumption that the presence of PT_PHDR and addresses of headers can be decided regardless of address information. This may seem natural because dot is not manipulated by a linker script. The other thing is that we have to drop the special rule for -T<section> in `getInitialDot`. If -Ttext is smaller than the image base, the headers will not be allocated with the old behavior (allocateHeaders is called) but always allocated with the new behavior. The behavior change is not a problem. Whether and where headers are allocated can vary among linkers, or ld.bfd across different versions (--enable-separate-code or not). It is thus advised to use a linker script with the PHDRS command to have a consistent behavior across linkers. If PT_PHDR is needed, an explicit --image-base can be a simpler alternative. Differential Revision: https://reviews.llvm.org/D67325 llvm-svn: 371957 Notes: svn path=/projects/clang1000-import/; revision=358681
* Merge ^/vendor/llvm-project/release-10.x up to its last change (upstreamDimitry Andric2020-02-2747-347/+529
| | | | | | | commit llvmorg-10.0.0-rc2-70-ge5cb70267e7), and bump versions. Notes: svn path=/projects/clang1000-import/; revision=358399
* Merge commit 2e24219d3 from llvm git (by Hans Wennborg):Dimitry Andric2020-02-273-15/+20
| | | | | | | | | | | | | | | | | | | | | | | [MC][ARM] Resolve some pcrel fixups at assembly time (PR44929) MC currently does not emit these relocation types, and lld does not handle them. Add FKF_Constant as a work-around of some ARM code after D72197. Eventually we probably should implement these relocation types. By Fangrui Song! Differential revision: https://reviews.llvm.org/D72892 This re-enables using the arm 'adr' pseudo instruction on global symbols again. It was broken as a side-effect of upstream commit 2bfee35cb, which lead to "error: unsupported relocation on symbol" when assembling such constructs, which are used in e.g. sys/arm/arm/locore-v[46].S. PR: 244251 Notes: svn path=/projects/clang1000-import/; revision=358396
* Merge commit 62654cab7 from llvm git (by me):Dimitry Andric2020-02-162-6/+15
| | | | | | | | | | | | | | | | | | | | | Restore functionality of --sysroot on FreeBSD after b18cb9c47 After b18cb9c47, clang would sometimes prefer the host C++ includes (e.g. in /usr/include/c++/v1) before those specified via --sysroot. While this behavior may be desirable on Linux, it is not so on FreeBSD, where we make extensive use of --sysroot during the build of the base system. In that case, clang must *not* search outside the sysroot, except for its own internal headers. Add an override addLibCxxIncludePaths() to restore the old behavior, which is to simply append /usr/include/c++/v1 to the specified sysroot. While here, apply clang-format to the FreeBSD specific toolchain files. Fixes PR44923. Notes: svn path=/projects/clang1000-import/; revision=357999
* Merge commit 221c5af4e from llvm git (by Nico Weber):Dimitry Andric2020-02-151-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a -Wbitwise-conditional-parentheses warning in _LIBUNWIND_ARM_EHABI libunwind builds ``` src/UnwindCursor.hpp:1344:51: error: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Werror,-Wbitwise-conditional-parentheses] _info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum? ~~~~~~~~~~~ ^ src/UnwindCursor.hpp:1344:51: note: place parentheses around the '|' expression to silence this warning _info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum? ^ ( ) src/UnwindCursor.hpp:1344:51: note: place parentheses around the '?:' expression to evaluate it first _info.flags = isSingleWordEHT ? 1 : 0 | scope32 ? 0x2 : 0; // Use enum? ^ ( ) ``` But `0 |` is a no-op for either of those two interpretations, so I think what was meant here was ``` _info.flags = (isSingleWordEHT ? 1 : 0) | (scope32 ? 0x2 : 0); // Use enum? ``` Previously, if `isSingleWordEHT` was set, bit 2 would never be set. Now it is. From what I can tell, the only thing that checks these bitmask is ProcessDescriptors in Unwind-EHABI.cpp, and that only cares about bit 1, so in practice this shouldn't have much of an effect. Differential Revision: https://reviews.llvm.org/D73890 This fixes the above errors when building libunwind for arm variants. Notes: svn path=/projects/clang1000-import/; revision=357965
* Merge ^/vendor/llvm-project/release-10.x up to its last change (upstreamDimitry Andric2020-02-15158-1377/+2870
| | | | | | | | commit llvmorg-10.0.0-rc2-0-g90c78073f73), bump versions, and update build glue. Notes: svn path=/projects/clang1000-import/; revision=357964
* Revert upstream lld r371957 (git commit 06bb7dfbd) by Fangrui Song:Dimitry Andric2020-01-292-19/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ELF] Map the ELF header at imageBase If there is no readonly section, we map: * The ELF header at imageBase+maxPageSize * Program headers at imageBase+maxPageSize+sizeof(Ehdr) * The first section .text at imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers) Due to the interaction between Writer<ELFT>::fixSectionAlignments and LinkerScript::allocateHeaders, `alignDown(p_vaddr(R PT_LOAD)) = alignDown(p_vaddr(RX PT_LOAD))`. The RX PT_LOAD will override the R PT_LOAD at runtime, which is not ideal: ``` // PHDR at 0x401034, should be 0x400034 PHDR 0x000034 0x00401034 0x00401034 0x000a0 0x000a0 R 0x4 // R PT_LOAD contains just Ehdr and program headers. // At 0x401000, should be 0x400000 LOAD 0x000000 0x00401000 0x00401000 0x000d4 0x000d4 R 0x1000 LOAD 0x0000d4 0x004010d4 0x004010d4 0x00001 0x00001 R E 0x1000 ``` * createPhdrs allocates the headers to the R PT_LOAD. * fixSectionAlignments assigns `imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers)` (formula: `alignTo(dot, maxPageSize) + dot % config->maxPageSize`) to addrExpr of .text * allocateHeaders computes the minimum address among SHF_ALLOC sections, i.e. addr(.text) * allocateHeaders sets address of ELF header to `addr(.text)-sizeof(Ehdr)-sizeof(program headers) = imageBase+maxPageSize` The main observation is that when the SECTIONS command is not used, we don't have to call allocateHeaders. This requires an assumption that the presence of PT_PHDR and addresses of headers can be decided regardless of address information. This may seem natural because dot is not manipulated by a linker script. The other thing is that we have to drop the special rule for -T<section> in `getInitialDot`. If -Ttext is smaller than the image base, the headers will not be allocated with the old behavior (allocateHeaders is called) but always allocated with the new behavior. The behavior change is not a problem. Whether and where headers are allocated can vary among linkers, or ld.bfd across different versions (--enable-separate-code or not). It is thus advised to use a linker script with the PHDRS command to have a consistent behavior across linkers. If PT_PHDR is needed, an explicit --image-base can be a simpler alternative. Differential Revision: https://reviews.llvm.org/D67325 llvm-svn: 371957 This causes "ld: error: output file too large: 18446744073707016908 bytes" when linking our loader_4th and loader_lua. Clearly, something is wrong when using -Ttext 0x0: I will file an upstream bug report for this. Notes: svn path=/projects/clang1000-import/; revision=357259
* Prefer upstream RISC-V additions in libunwind instead of ours, as theseDimitry Andric2020-01-287-510/+1
| | | | | | | arrived via roundabout way upstream, and got updated in the mean time. Notes: svn path=/projects/clang1000-import/; revision=357209
* Update build glue for lldb (MK_LLDB=yes). Also update lldb's generatedDimitry Andric2020-01-272-1/+22
| | | | | | | | Config.h, disable a few more parts in the code we don't use, and add a pre-generated man page. Notes: svn path=/projects/clang1000-import/; revision=357174
* Update build glue for lld (MK_LLD=yes). Also update invocation ofDimitry Andric2020-01-261-1/+1
| | | | | | | elf::link() in lld.cpp. Notes: svn path=/projects/clang1000-import/; revision=357160
* Further reduce diffs between upstream and our version.Dimitry Andric2020-01-251-2/+1
| | | | Notes: svn path=/projects/clang1000-import/; revision=357118
* Update FREEBSD-Xlist.Dimitry Andric2020-01-251-0/+1
| | | | Notes: svn path=/projects/clang1000-import/; revision=357117
* Merge ^/vendor/lvm-project/release-10.x up to its last change (upstreamDimitry Andric2020-01-24145-1094/+4899
| | | | | | | commit llvmorg-10-init-17538-gd11abddb32f). Notes: svn path=/projects/clang1000-import/; revision=357099
* Merge ^/vendor/lvm-project/release-10.x up to its last change (upstreamDimitry Andric2020-01-243-24/+35
| | | | | | | commit c4a134a51). Notes: svn path=/projects/clang1000-import/; revision=357096
* Merge ^/vendor/lvm-project/master up to its last change (upstream commitDimitry Andric2020-01-243290-74369/+148873
| | | | | | | e26a78e70), and resolve conflicts. Notes: svn path=/projects/clang1000-import/; revision=357095
* Merge ^/vendor/llvm-openmp/dist up to its last change, and resolve conflicts.Dimitry Andric2020-01-2324-176/+686
| | | | Notes: svn path=/projects/clang1000-import/; revision=357059
* Merge ^/vendor/lldb/dist up to its last change, and resolve conflicts.Dimitry Andric2020-01-23814-60882/+26191
| | | | Notes: svn path=/projects/clang1000-import/; revision=357058
* Merge ^/vendor/lld/dist up to its last change, and resolve conflicts.Dimitry Andric2020-01-23104-2269/+3941
| | | | Notes: svn path=/projects/clang1000-import/; revision=357057
* Merge ^/vendor/llvm-libunwind/dist up to its last change, and resolve conflicts.Dimitry Andric2020-01-235-38/+51
| | | | Notes: svn path=/projects/clang1000-import/; revision=357036
* Merge ^/vendor/libc++/dist up to its last change, and resolve conflicts.Dimitry Andric2020-01-2353-915/+1105
| | | | Notes: svn path=/projects/clang1000-import/; revision=357035
* Merge ^/vendor/compiler-rt/dist up to its last change, and resolve conflicts.Dimitry Andric2020-01-22374-3107/+4609
| | | | Notes: svn path=/projects/clang1000-import/; revision=356999
* Merge ^/vendor/clang/dist up to its last change, and resolve conflicts.Dimitry Andric2020-01-22739-16776/+45142
| | | | Notes: svn path=/projects/clang1000-import/; revision=356998
* Reduce diff between stock DWARFContext.cpp and ours.Dimitry Andric2020-01-221-1/+1
| | | | Notes: svn path=/projects/clang1000-import/; revision=356997
* Merge ^/vendor/llvm/dist up to its last change, and resolve conflicts.Dimitry Andric2020-01-222075-48224/+116745
| | | | Notes: svn path=/projects/clang1000-import/; revision=356992
* Merge ^/head r356920 through r356930.Dimitry Andric2020-01-207-16/+36
|\ | | | | | | Notes: svn path=/projects/clang1000-import/; revision=356931
| * Merge commit bc4bc5aa0 from llvm git (by Justin Hibbits):Dimitry Andric2020-01-207-16/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add 8548 CPU definition and attributes 8548 CPU is GCC's name for the e500v2, so accept this in clang. The e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as well, as GCC does. Differential Revision: https://reviews.llvm.org/D67787 Merge commit ff0311c4b from llvm git (by Justin Hibbits): [PowerPC]: Add powerpcspe target triple subarch component Summary: This allows the use of '-target powerpcspe-unknown-linux-gnu' or 'powerpcspe-unknown-freebsd' to be used, instead of '-target powerpc-unknown-linux-gnu -mspe'. Reviewed By: dim Differential Revision: https://reviews.llvm.org/D72014 Merge commit ba91dffaf from llvm git (by Fangrui Song): [Driver][PowerPC] Move powerpcspe logic from cc1 to Driver Follow-up of D72014. It is more appropriate to use a target feature instead of a SubTypeArch to express the difference. Reviewed By: #powerpc, jhibbits Differential Revision: https://reviews.llvm.org/D72433 commit 36eedfcb3 from llvm git (by Justin Hibbits): [PowerPC] Fix powerpcspe subtarget enablement in llvm backend Summary: As currently written, -target powerpcspe will enable SPE regardless of disabling the feature later on in the command line. Instead, change this to just set a default CPU to 'e500' instead of a generic CPU. As part of this, add FeatureSPE to the e500 definition. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D72673 These are needed to unbreak the build for powerpcspe. Requested by: jhibbits MFC after: 1 week Notes: svn path=/head/; revision=356929
* | Merge ^/vendor/llvm-project/master until just before r356843.Dimitry Andric2020-01-209-379/+0
|/ | | | Notes: svn path=/projects/clang1000-import/; revision=356921
* Merge commit 894f742acb from llvm git (by me):Alex Richardson2020-01-163-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228 Merge commit 8e8ccf47 from llvm git (by me) [MIPS] Don't emit R_(MICRO)MIPS_JALR relocations against data symbols The R_(MICRO)MIPS_JALR optimization only works when used against functions. Using the relocation against a data symbol (e.g. function pointer) will cause some linkers that don't ignore the hint in this case (e.g. LLD prior to commit 5bab291) to generate a relative branch to the data symbol which crashes at run time. Before this patch, LLVM was erroneously emitting these relocations against local-dynamic TLS function pointers and global function pointers with internal visibility. Reviewers: atanasyan, jrtc27, vstefanovic Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72571 These two changes should allow using lld for MIPS64 (and maybe also MIPS32) by default. The second commit is not strictly necessary for clang+lld since LLD9 will not perform the R_MIPS_JALR optimization (it was only added for 10) but it is probably required in order to use recent ld.bfd. Reviewed By: dim, emaste MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D23203 Notes: svn path=/head/; revision=356789
* Merge commit f46ba4f07 from llvm git (by Simon Atanasyan):Dimitry Andric2020-01-133-2/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [mips] Use less registers to load address of TargetExternalSymbol There is no pattern matched `add hi, (MipsLo texternalsym)`. As a result, loading an address of 32-bit symbol requires two registers and one more additional instruction: ``` addiu $1, $zero, %lo(foo) lui $2, %hi(foo) addu $25, $2, $1 ``` This patch adds the missed pattern and enables generation more effective set of instructions: ``` lui $1, %hi(foo) addiu $25, $1, %lo(foo) ``` Differential Revision: https://reviews.llvm.org/D66771 llvm-svn: 370196 Merge commit 59bb3609f from llvm git (by Simon Atanasyan): [mips] Fix 64-bit address loading in case of applying 32-bit mask to the result If result of 64-bit address loading combines with 32-bit mask, LLVM tries to optimize the code and remove "redundant" loading of upper 32-bits of the address. It leads to incorrect code on MIPS64 targets. MIPS backend creates the following chain of commands to load 64-bit address in the `MipsTargetLowering::getAddrNonPICSym64` method: ``` (add (shl (add (shl (add %highest(sym), %higher(sym)), 16), %hi(sym)), 16), %lo(%sym)) ``` If the mask presents, LLVM decides to optimize the chain of commands. It really does not make sense to load upper 32-bits because the 0x0fffffff mask anyway clears them. After removing redundant commands we get this chain: ``` (add (shl (%hi(sym), 16), %lo(%sym)) ``` There is no patterns matched `(MipsHi (i64 symbol))`. Due a bug in `SYM_32` predicate definition, backend incorrectly selects a pattern for a 32-bit symbols and uses the `lui` instruction for loading `%hi(sym)`. As a result we get incorrect set of instructions with unnecessary 16-bit left shifting: ``` lui at,0x0 R_MIPS_HI16 foo dsll at,at,0x10 daddiu at,at,0 R_MIPS_LO16 foo ``` This patch resolves two problems: - Fix `SYM_32/SYM_64` predicates to prevent selection of patterns dedicated to 32-bit symbols in case of using N64 ABI. - Add missed patterns for 64-bit symbols for `%hi/%lo`. Fix PR42736. Differential Revision: https://reviews.llvm.org/D66228 llvm-svn: 370268 These two commits fix a miscompilation of the kernel for mips64, and should allow clang to be used as the default compiler for mips64. Requested by: arichards MFC after: 3 days Notes: svn path=/head/; revision=356701
* revert r356513: libunwind: untested attempt to fix sparc64 buildEd Maste2020-01-092-3/+2
| | | | | | | | | The patch is untested and is almost certainly insufficient. Per the author's request, revert until someone with access to sparc64 hardware can test and report. Notes: svn path=/head/; revision=356552
* libunwind: untested attempt to fix sparc64 buildEd Maste2020-01-082-2/+3
| | | | | | | | | | | | | | | | sparc64 is the only architecture currently using the DWARF unwinder from GCC 4.2.1. Old GCC and related libraries are being removed soon; absent other changes sparc64 would be left with no unwinder when that happens. Instead, commit these changes which should at least allow the LLVM unwinder to build. Someone with access to the obolete sparc64 hardware supported by FreeBSD will need to test the result. PR: 233405 Submitted by: cem Notes: svn path=/head/; revision=356513
* Merge commit 189b7393d from llvm git (by John Baldwin):Dimitry Andric2020-01-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [lld][RISCV] Use an e_flags of 0 if there are only binary input files. Summary: If none of the input files are ELF object files (for example, when generating an object file from a single binary input file via "-b binary"), use a fallback value for the ELF header flags instead of crashing with an assertion failure. Reviewers: MaskRay, ruiu, espindola Reviewed By: MaskRay, ruiu Subscribers: kevans, grimar, emaste, arichardson, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27 Tags: #llvm Differential Revision: https://reviews.llvm.org/D71101 This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld. Requested by: jhb MFC after: 1 week X-MFC-With: r353358 Notes: svn path=/head/; revision=356333
* Merge commit d7be3eab5 from llvm git (by Luís Marques):Dimitry Andric2020-01-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | [RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678 This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld. Requested by: jhb MFC after: 1 week X-MFC-With: r353358 Notes: svn path=/head/; revision=356332
* Merge commit c6b09bff5 from llvm git (by Luís Marques):Dimitry Andric2020-01-031-40/+0
| | | | | | | | | | | | | | | | | | | | | | | | | [RISCV] Fix wrong CFI directives Summary: Removes CFI CFA directives that could incorrectly propagate beyond the basic block they were inteded for. Specifically it removes the epilogue CFI directives. See the branch_and_tail_call test for an example of the issue. Should fix the stack unwinding issues caused by the incorrect directives. Reviewers: asb, lenary, shiva0217 Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D69723 This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld. Requested by: jhb MFC after: 1 week X-MFC-With: r353358 Notes: svn path=/head/; revision=356331
* Merge commit da7b129b1 from llvm git (by James Clarke):Dimitry Andric2020-01-031-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [RISCV] Don't force Local Exec TLS for non-PIC Summary: Forcing Local Exec TLS requires the use of copy relocations. Copy relocations need special handling in the runtime linker when being used against TLS symbols, which is present in glibc, but not in FreeBSD nor musl, and so cannot be relied upon. Moreover, copy relocations are a hack that embed the size of an object in the ABI when it otherwise wouldn't be, and break protected symbols (which are expected to be DSO local), whilst also wasting space, thus they should be avoided whenever possible. As discussed in D70398, RISC-V should move away from forcing Local Exec, and instead use Initial Exec like other targets, with possible linker relaxation to follow. The RISC-V GCC maintainers also intend to adopt this more-conventional behaviour (see https://github.com/riscv/riscv-elf-psabi-doc/issues/122). Reviewers: asb, MaskRay Reviewed By: MaskRay Subscribers: emaste, krytarowski, hiraditya, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, llvm-commits, bsdjhb Tags: #llvm Differential Revision: https://reviews.llvm.org/D70649 This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld. Requested by: jhb MFC after: 1 week X-MFC-With: r353358 Notes: svn path=/head/; revision=356330
* Merge commit 41449c58c from llvm git (by Roger Ferrer Ibanez):Dimitry Andric2020-01-031-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [RISCV] Fix evaluation of %pcrel_lo The following testcase function: .Lpcrel_label1: auipc a0, %pcrel_hi(other_function) addi a1, a0, %pcrel_lo(.Lpcrel_label1) .p2align 2 # Causes a new fragment to be emitted .type other_function,@function other_function: ret exposes an odd behaviour in which only the %pcrel_hi relocation is evaluated but not the %pcrel_lo. $ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump -d -r - <stdin>: file format ELF64-riscv Disassembly of section .text: 0000000000000000 function: 0: 17 05 00 00 auipc a0, 0 4: 93 05 05 00 mv a1, a0 0000000000000004: R_RISCV_PCREL_LO12_I other_function+4 0000000000000008 other_function: 8: 67 80 00 00 ret The reason seems to be that in RISCVAsmBackend::shouldForceRelocation we only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we consider the section. This usually works but there are cases where the section may still be the same but the fragment may be another one. In that case we end forcing a %pcrel_lo relocation without any %pcrel_hi. This patch makes RISCVAsmBackend::shouldForceRelocation use the section, if any, to determine if the relocation must be forced or not. Differential Revision: https://reviews.llvm.org/D60657 This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld. Requested by: jhb MFC after: 1 week X-MFC-With: r353358 Notes: svn path=/head/; revision=356329
* Merge commit 468a0cb5f from llvm git (by Craig Topper):Dimitry Andric2020-01-012-1/+74
| | | | | | | | | | | | | | | | | | | | | | | | | [X86] Add X87 FCMOV support to X86FlagsCopyLowering. Fixes PR44396 Merge commit 86f48999f from llvm git (by Craig Topper): [X86] Fix typo in getCMovOpcode. The 64-bit HasMemoryOperand line was using CMOV32rm instead of CMOV64rm. Not sure how to test this. We have no test coverage that passes true for HasMemoryOperand. This fixes 'Assertion failed: (MI.findRegisterDefOperand(X86::EFLAGS) && "Expected a def of EFLAGS for this instruction!"), function runOnMachineFunction' when compiling the misc/gpsim port for i386. Reported by: yuri Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=44396 MFC after: 1 week Notes: svn path=/head/; revision=356256
* [PowerPC64] Starting from FreeBSD 13.0, default to ELFv2 ABIJustin Hibbits2019-12-272-2/+33
| | | | | | | | | | | | | | | This changes the LLVM default powerpc64 ABI to ELFv2, if target OS is FreeBSD >= 13.0 This will also be sent upstream. Submitted by: alfredo.junior_eldorado.org.br Reviewed by: dim, luporl Relnotes: YES Differential Revision: https://reviews.freebsd.org/D20383 Notes: svn path=/head/; revision=356112
* [PowerPC] enable atomic.c in compiler_rt and do not check and forcesJustin Hibbits2019-12-262-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | lock/lock_free decisions in compiled time Summary: Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime decision about lock/lock_free. At compiling time, if clang can't decide if atomic operation can be lock free, it emits calls to external functions like `__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and `__atomic_always_lock_free`, postponing decision to a runtime check. According to LLVM code documentation, the mechanism exists due to differences between x86_64 processors that can't be decided at runtime. On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock free, so we force the decision at compile time and avoid having to implement it in an external library. This patch was made after 32 bit users testing the PowePC32 bit ISO reported llvm could not be compiled with in-base llvm due to `__atomic_load8` not implemented. Submitted by: alfredo.junior_eldorado.org.br Reviewed by: jhibbits, dim Differential Revision: https://reviews.freebsd.org/D22549 Notes: svn path=/head/; revision=356104
* Merge commit d3aeac8e2 from llvm git (by Justin Hibbits)Dimitry Andric2019-12-261-1/+6
| | | | | | | | | | | | | | | | | | | | | | | [PowerPC] Only use PLT annotations if using PIC relocation model Summary: The default static (non-PIC, non-PIE) model for 32-bit powerpc does not use @PLT annotations and relocations in GCC. LLVM shouldn't use @PLT annotations either, because it breaks secure-PLT linking with (some versions of?) GNU LD. Update the available-externally.ll test to reflect that default mode should be the same as the static relocation, by using the same check prefix. Reviewed by: sfertile Differential Revision: https://reviews.llvm.org/D70570 Reviewed by: jhibbits Differential Revision: https://reviews.freebsd.org/D22913 Notes: svn path=/head/; revision=356100
* Merge commit f97936fab from llvm git (by Eric Fiselier):Dimitry Andric2019-12-226-25/+25
| | | | | | | | | | | | | | | | | | | | [libc++] Cleanup and enable multiple warnings. Too many warnings are being disabled too quickly. Warnings are important to keeping libc++ correct. This patch re-enables two warnings: -Wconstant-evaluated and -Wdeprecated-copy. In future, all warnings disabled for the test suite should require an attached bug. The bug should state the plan for re-enabling that warning, or a strong case why it should remain disabled. This should fix a number of new g++ 9 warnings. Requested by: rlibby MFC after: 3 days Notes: svn path=/head/; revision=356005
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2019-12-2259-424/+977
| | | | | | | | | | | | | | | | | | 9.0.1 final release c1a0a213378a458fbea1a5c77b315c7dce08fd05. Release notes for llvm, clang, lld and libc++ 9.0.1 will become available here: https://releases.llvm.org/9.0.1/docs/ReleaseNotes.html https://releases.llvm.org/9.0.1/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.1/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.1/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month Notes: svn path=/head/; revision=356004
* Consolidate FREEBSD-Xlist files of different llvm sub-projects into one.Dimitry Andric2019-12-2010-1058/+1000
| | | | Notes: svn path=/head/; revision=355959
* Merge diff elimination updates from r355953 into vendor/llvm-project.Dimitry Andric2019-12-201-1/+1
| | | | Notes: svn path=/head/; revision=355957
* Move all sources from the llvm project into contrib/llvm-project.Dimitry Andric2019-12-209508-0/+4743910
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
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-11 20:29:30 +0000