- 17 Apr, 2018 1 commit
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r329761 | gberry | 2018-04-10 14:43:03 -0700 (Tue, 10 Apr 2018) | 13 lines [AArch64][Falkor] Fix bug in Falkor HWPF collision avoidance pass. Summary: When inserting MOVs to avoid Falkor HWPF collisions, the non-base register operand of load instructions (e.g. a register offset) was not being considered live, so it could potentially have been used as a scratch register, clobbering the actual offset value. Reviewers: mcrosier Subscribers: rengolin, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D45502 ``` --------------------------------------------------------------------- llvm-svn: 330209
-
- 14 Apr, 2018 1 commit
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r322373 | d0k | 2018-01-12 07:03:24 -0800 (Fri, 12 Jan 2018) | 4 lines [PowerPC] Don't miscompile rotate+mask into an ANDIo if it can't recreate the immediate I'm not even sure if this transform is ever worth it, but this at least stops the bleeding. ``` --------------------------------------------------------------------- llvm-svn: 330082
-
- 13 Apr, 2018 1 commit
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r329852 | nemanjai | 2018-04-11 14:25:44 -0700 (Wed, 11 Apr 2018) | 8 lines [PowerPC] Fix condition for 64-bit rotate when replacing r+r instr with r+i This patch fixes https://bugs.llvm.org/show_bug.cgi?id=37039 The condition only covers one of the two 64-bit rotate instructions. This just adds the second (RLDICLo). Patch by Josh Stone. ``` --------------------------------------------------------------------- llvm-svn: 330076
-
- 11 Apr, 2018 8 commits
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r329359 | manojgupta | 2018-04-05 15:47:25 -0700 (Thu, 05 Apr 2018) | 11 lines Attempt to fix Mips breakages. Summary: Replace ArrayRefs by actual std::array objects so that there are no dangling references. Reviewers: rsmith, gkistanova Subscribers: sdardis, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D45338 ``` --------------------------------------------------------------------- ------------------------------------------------------------------------ r329363 | manojgupta | 2018-04-05 16:23:29 -0700 (Thu, 05 Apr 2018) | 5 lines Fix lld-x86_64-darwin13 build fails. Use double braces in std::array initialization to keep Darwin builders happy. ------------------------------------------------------------------------ llvm-svn: 329859
-
Tom Stellard authored
```--------------------------------------------------------------------- r326521 | indutny | 2018-03-01 16:59:27 -0800 (Thu, 01 Mar 2018) | 13 lines [ArgumentPromotion] don't break musttail invariant PR36543 Summary: Do not break musttail invariant by promoting arguments of musttail callee or caller. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv, fhahn, rnk Reviewed By: rnk Subscribers: rnk, llvm-commits Differential Revision: https://reviews.llvm.org/D43926 ``` --------------------------------------------------------------------- llvm-svn: 329858
-
Tom Stellard authored
llvm-svn: 329857
-
Tom Stellard authored
```--------------------------------------------------------------------- r326404 | rnk | 2018-02-28 17:19:18 -0800 (Wed, 28 Feb 2018) | 14 lines [IPSCCP] do not break musttail invariant (PR36485) Do not replace results of `musttail` calls with a constant if the call itself can't be removed. Do not zap returns of `musttail` callees, if the call site can't be removed and replaced with a constant. Do not zap returns of `musttail`-calling blocks, this breaks invariant too. Patch by Fedor Indutny Differential Revision: https://reviews.llvm.org/D43695 ``` --------------------------------------------------------------------- llvm-svn: 329855
-
Simon Dardis authored
```--------------------------------------------------------------------- r325713 | sdardis | 2018-02-21 20:01:43 +0000 (Wed, 21 Feb 2018) | 5 lines [mips][lld] Address post commit review nit. Address @ruiu's post commit review comment about a value which is intended to be a unsigned 32 bit integer as using uint32_t rather than unsigned. ``` --------------------------------------------------------------------- ------------------------------------------------------------------------ r325647 | sdardis | 2018-02-20 23:49:17 +0000 (Tue, 20 Feb 2018) | 27 lines [mips][lld] Spectre variant two mitigation for MIPSR2 This patch provides migitation for CVE-2017-5715, Spectre variant two, which affects the P5600 and P6600. It implements the LLD part of -z hazardplt. Like the Clang part of this patch, I have opted for that specific option name in case alternative migitation methods are required in the future. The mitigation strategy suggested by MIPS for these processors is to use hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard barrier variants of the 'jalr' and 'jr' instructions respectively. These instructions impede the execution of instruction stream until architecturally defined hazards (changes to the instruction stream, privileged registers which may affect execution) are cleared. These instructions in MIPS' designs are not speculated past. These instructions are defined by the MIPS32R2 ISA, so this mitigation method is not compatible with processors which implement an earlier revision of the MIPS ISA. For LLD, this changes PLT stubs to use 'jalr.hb' and 'jr.hb'. Reviewers: atanasyan, ruiu Differential Revision: https://reviews.llvm.org/D43488 ------------------------------------------------------------------------ llvm-svn: 329800
-
Simon Dardis authored
```--------------------------------------------------------------------- r325651 | sdardis | 2018-02-21 00:05:05 +0000 (Wed, 21 Feb 2018) | 34 lines [mips] Spectre variant two mitigation for MIPSR2 This patch provides mitigation for CVE-2017-5715, Spectre variant two, which affects the P5600 and P6600. It provides the option -mindirect-jump=hazard, which instructs the LLVM backend to replace indirect branches with their hazard barrier variants. This option is accepted when targeting MIPS revision two or later. The migitation strategy suggested by MIPS for these processors is to use two hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard barrier variants of the 'jalr' and 'jr' instructions respectively. These instructions impede the execution of instruction stream until architecturally defined hazards (changes to the instruction stream, privileged registers which may affect execution) are cleared. These instructions in MIPS' designs are not speculated past. These instructions are used with the option -mindirect-jump=hazard when branching indirectly and for indirect function calls. These instructions are defined by the MIPS32R2 ISA, so this mitigation method is not compatible with processors which implement an earlier revision of the MIPS ISA. Implementation note: I've opted to provide this as an -mindirect-jump={hazard,...} style option in case alternative mitigation methods are required for other implementations of the MIPS ISA in future, e.g. retpoline style solutions. Reviewers: atanasyan Differential Revision: https://reviews.llvm.org/D43487 ``` --------------------------------------------------------------------- llvm-svn: 329799 -
Simon Dardis authored
```--------------------------------------------------------------------- r325653 | sdardis | 2018-02-21 00:06:53 +0000 (Wed, 21 Feb 2018) | 31 lines [mips] Spectre variant two mitigation for MIPSR2 This patch provides mitigation for CVE-2017-5715, Spectre variant two, which affects the P5600 and P6600. It implements the LLVM part of -mindirect-jump=hazard. It is _not_ enabled by default for the P5600. The migitation strategy suggested by MIPS for these processors is to use hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard barrier variants of the 'jalr' and 'jr' instructions respectively. These instructions impede the execution of instruction stream until architecturally defined hazards (changes to the instruction stream, privileged registers which may affect execution) are cleared. These instructions in MIPS' designs are not speculated past. These instructions are used with the attribute +use-indirect-jump-hazard when branching indirectly and for indirect function calls. These instructions are defined by the MIPS32R2 ISA, so this mitigation method is not compatible with processors which implement an earlier revision of the MIPS ISA. Performance benchmarking of this option with -fpic and lld using -z hazardplt shows a difference of overall 10%~ time increase for the LLVM testsuite. Certain benchmarks such as methcall show a substantially larger increase in time due to their nature. Reviewers: atanasyan, zoran.jovanovic Differential Revision: https://reviews.llvm.org/D43486 ``` --------------------------------------------------------------------- llvm-svn: 329798
-
Florian Hahn authored
[CallSiteSplitting] properly split musttail calls. The original author was Fedor Indutny <fedor@indutny.com>. `musttail` calls can't be naively splitted. The split blocks must include not only the call instruction itself, but also (optional) `bitcast` and `return` instructions that follow it. Clone `bitcast` and `ret`, place them into the split blocks, and remove the tail block when done. Reviewers: junbuml, mcrosier, davidxl, davide, fhahn Reviewed By: fhahn Subscribers: JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D43729 llvm-svn: 329793
-
- 10 Apr, 2018 6 commits
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r328755 | gbiv | 2018-03-28 20:12:03 -0700 (Wed, 28 Mar 2018) | 10 lines [MemorySSA] Turn an assert into a condition Eli pointed out that variadic functions are totally a thing, so this assert is incorrect. No test-case is provided, since the only way this assert fires is if a specific DenseMap falls back to doing `isEqual` checks, and that seems fairly brittle (and requires a pyramid of growing `call void (i8, ...) @varargs(i8 0)`). ``` --------------------------------------------------------------------- llvm-svn: 329670
-
Tom Stellard authored
```--------------------------------------------------------------------- r328829 | manojgupta | 2018-03-29 14:11:15 -0700 (Thu, 29 Mar 2018) | 23 lines [AArch64]: Add support for parsing rN registers. Summary: Allow rN registers to be simply parsed as correspoing xN registers. The "register ... asm("rN")" is an command to the compiler's register allocator, not an operand to any individual assembly instruction. GCC documents this syntax as "...the name of the register that should be used." This is needed to support the changes in Linux kernel (see https://lkml.org/lkml/2018/3/1/268 ) Note: This will add support only for the limited use case of register ... asm("rN"). Any other uses that make rN leak into assembly are not supported. Reviewers: kristof.beyls, rengolin, peter.smith, t.p.northover Reviewed By: peter.smith Subscribers: javed.absar, eraman, cfe-commits, srhines Differential Revision: https://reviews.llvm.org/D44815 ``` --------------------------------------------------------------------- llvm-svn: 329669 -
Tom Stellard authored
```--------------------------------------------------------------------- r326769 | bjope | 2018-03-06 00:47:07 -0800 (Tue, 06 Mar 2018) | 28 lines [DebugInfo] Discard invalid DBG_VALUE instructions in LiveDebugVariables Summary: This is a workaround for pr36417 https://bugs.llvm.org/show_bug.cgi?id=36417 LiveDebugVariables will now verify that the DBG_VALUE instructions are sane (prior to register allocation) by asking LIS if a virtual register used in the DBG_VALUE is live (or dead def) in the slot index before the DBG_VALUE. If it isn't sane the DBG_VALUE is discarded. One pass that was identified as introducing non-sane DBG_VALUE instructtons, when analysing pr36417, was the DAG->DAG Instruction Selection. It sometimes inserts DBG_VALUE instructions referring to a virtual register that is defined later in the same basic block. So it is a use before def kind of problem. The DBG_VALUE is typically inserted in the beginning of a basic block when this happens. The problem can be seen in the test case test/DebugInfo/X86/dbg-value-inlined-parameter.ll Reviewers: aprantl, rnk, probinson Reviewed By: aprantl Subscribers: vsk, davide, alexcrichton, Ka-Ka, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D43956 ``` --------------------------------------------------------------------- ------------------------------------------------------------------------ r326780 | bjope | 2018-03-06 05:23:28 -0800 (Tue, 06 Mar 2018) | 6 lines Fixup for rL326769 (RegState::Debug is being truncated to a bool) I obviously messed up arguments to MachineOperand::CreateReg in rL326769. This should make it work as intended. Thanks to RKSimon for spotting this. ------------------------------------------------------------------------ llvm-svn: 329668
-
Tom Stellard authored
```--------------------------------------------------------------------- r327016 | labath | 2018-03-08 07:52:46 -0800 (Thu, 08 Mar 2018) | 8 lines Install lldb's SB headers (pr36630) These were removed in r309021 in what looks like an accidentally committed change. This brings them back. I also rename the header component to lldb-headers (instead of lldb_headers) to match the llvm style and add a special install-lldb-headers target, which installs just the headers. ``` --------------------------------------------------------------------- llvm-svn: 329664
-
Tom Stellard authored
```--------------------------------------------------------------------- r328748 | gbiv | 2018-03-28 17:54:39 -0700 (Wed, 28 Mar 2018) | 12 lines [MemorySSA] Consider callsite args for hashing and equality. We use a `DenseMap<MemoryLocOrCall, MemlocStackInfo>` to keep track of prior work when optimizing uses in MemorySSA. Because we weren't accounting for callsite arguments in either the hash code or equality tests for `MemoryLocOrCall`s, we optimized uses too aggressively in some rare cases. Fix by Daniel Berlin. Should fix PR36883. ``` --------------------------------------------------------------------- llvm-svn: 329663
-
Tom Stellard authored
```--------------------------------------------------------------------- r329588 | tstellar | 2018-04-09 09:09:13 -0700 (Mon, 09 Apr 2018) | 11 lines AMDGPU: Initialize GlobalISel passes Summary: This fixes AMDGPU GlobalISel test failures when enabling the AMDGPU target without any other targets that use GlobalISel. Reviewers: arsenm Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, rovka, kristof.beyls, dstuttard, tpr, llvm-commits, t-tye Differential Revision: https://reviews.llvm.org/D45353 ``` --------------------------------------------------------------------- llvm-svn: 329662
-
- 09 Apr, 2018 6 commits
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r327651 | carrot | 2018-03-15 10:49:12 -0700 (Thu, 15 Mar 2018) | 9 lines [PPC] Avoid non-simple MVT in STBRX optimization PR35402 triggered this case. It bswap and stores a 48bit value, current STBRX optimization transforms it into STBRX. Unfortunately 48bit is not a simple MVT, there is no PPC instruction to support it, and it can't be automatically expanded by llvm, so caused a crash. This patch detects the non-simple MVT and returns early. Differential Revision: https://reviews.llvm.org/D44500 ``` --------------------------------------------------------------------- llvm-svn: 329641
-
Tom Stellard authored
```--------------------------------------------------------------------- r326376 | jdevlieghere | 2018-02-28 14:28:44 -0800 (Wed, 28 Feb 2018) | 12 lines [GlobalOpt] don't change CC of musttail calle(e|r) When the function has musttail call - its cc is fixed to be equal to the cc of the musttail callee. In such case (and in the case of the musttail callee), GlobalOpt should not change the cc to fastcc as it will break the invariant. This fixes PR36546 Patch by: Fedor Indutny (indutny) Differential revision: https://reviews.llvm.org/D43859 ``` --------------------------------------------------------------------- llvm-svn: 329634
-
Tom Stellard authored
```--------------------------------------------------------------------- r329052 | hans | 2018-04-03 02:28:21 -0700 (Tue, 03 Apr 2018) | 1 line UsersManual.rst: update text for /GX- to match r328708 ``` --------------------------------------------------------------------- llvm-svn: 329625
-
Tom Stellard authored
```--------------------------------------------------------------------- r328708 | hans | 2018-03-28 07:57:49 -0700 (Wed, 28 Mar 2018) | 1 line clang-cl: s/Enable/Disable/ in help text for /GX- ``` --------------------------------------------------------------------- llvm-svn: 329624
-
Tom Stellard authored
```--------------------------------------------------------------------- r322319 | matze | 2018-01-11 14:30:43 -0800 (Thu, 11 Jan 2018) | 7 lines PeepholeOptimizer: Fix for vregs without defs The PeepholeOptimizer would fail for vregs without a definition. If this was caused by an undef operand abort to keep the code simple (so we don't need to add logic everywhere to replicate the undef flag). Differential Revision: https://reviews.llvm.org/D40763 ``` --------------------------------------------------------------------- llvm-svn: 329619
-
Tom Stellard authored
```--------------------------------------------------------------------- r326535 | jvesely | 2018-03-01 18:50:22 -0800 (Thu, 01 Mar 2018) | 6 lines AMDGPU/GCN: Promote i16 ctpop i16 capable ASICs do not support i16 operands for this instruction. Add tablegen pattern to merge chained i16 additions. Differential Revision: https://reviews.llvm.org/D43985 ``` --------------------------------------------------------------------- llvm-svn: 329589
-
- 07 Apr, 2018 7 commits
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r328341 | apazos | 2018-03-23 10:53:27 -0700 (Fri, 23 Mar 2018) | 16 lines [ARM] Fix "Constant pool entry out of range!" in Thumb1 mode This patch fixes PR36658, "Constant pool entry out of range!" in Thumb1 mode. In ARMConstantIslands::optimizeThumb2JumpTables() in Thumb1 mode, adjustBBOffsetsAfter() is not calculating postOffset correctly by properly accounting for the padding that is required for the constant pool that immediately follows the jump table branch instruction. Reviewers: t.p.northover, eli.friedman Reviewed By: t.p.northover Subscribers: chrib, tstellar, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D44709 ``` --------------------------------------------------------------------- llvm-svn: 329487
-
Tom Stellard authored
```--------------------------------------------------------------------- r327761 | chandlerc | 2018-03-16 16:51:33 -0700 (Fri, 16 Mar 2018) | 20 lines [GlobalsAA] Fix a pretty terrible bug that has been in GlobalsAA for a long time. The key thing is that we need to create value handles for every function that we create a `FunctionInfo` object around. Without this, when that function is deleted we can end up creating a new function that collides with its address and look up a stale AA result. With that AA result we can in turn miscompile code in ways that break. This is seriously one of the most absurd miscompiles I've seen. It only reproduced for us recently and only when building a very large server with both ThinLTO and PGO. A *HUGE* shout out to Wei Mi who tracked all of this down and came up with this patch. I'm just landing it because I happened to still by at a computer. He or I can work on crafting a test case to hit this (now that we know what to target) but it'll take a while, and we've been chasing this for a long time and need it fix Right Now. ``` --------------------------------------------------------------------- llvm-svn: 329485
-
Tom Stellard authored
```--------------------------------------------------------------------- r327135 | hans | 2018-03-09 06:46:44 -0800 (Fri, 09 Mar 2018) | 7 lines CMake: Make libxml2 show up in --system-libs (PR36660) lib/WindowsManifest/CMakeLists.txt adds it to LLVM_SYSTEM_LIBS on that target, but it was never getting picked up in tools/llvm-config/CMakeLists.txt. Differential Revision: https://reviews.llvm.org/D44302 ``` --------------------------------------------------------------------- llvm-svn: 329482
-
Tom Stellard authored
```--------------------------------------------------------------------- r326843 | eugenezelenko | 2018-03-06 15:06:13 -0800 (Tue, 06 Mar 2018) | 6 lines [Transforms] Add missing header for InstructionCombining.cpp, in order to export LLVMInitializeInstCombine as extern "C". Fixes PR35947. Patch by Brenton Bostick. Differential revision: https://reviews.llvm.org/D44140 ``` --------------------------------------------------------------------- llvm-svn: 329480
-
Tom Stellard authored
```--------------------------------------------------------------------- r327099 | rsmith | 2018-03-08 18:00:01 -0800 (Thu, 08 Mar 2018) | 3 lines PR36645: Go looking for an appropriate array bound when constant-evaluating a name of an array object. ``` --------------------------------------------------------------------- llvm-svn: 329478
-
Tom Stellard authored
```--------------------------------------------------------------------- r326840 | ctopper | 2018-03-06 14:45:31 -0800 (Tue, 06 Mar 2018) | 5 lines [X86] Fix a typo in Host.cpp that causes us to misidentify KNL, Silvermont, Goldmont and probably other CPUs for -march=native I think most of the Intel Core CPUs and recent AMD CPUs are unaffected. All the CPUs that have a "subtype" should work. The ones that were broken are the ones that are a "type" with no subtypes. Fixes PR36619. ``` --------------------------------------------------------------------- llvm-svn: 329473
-
Tom Stellard authored
llvm-svn: 329469
-
- 02 Mar, 2018 4 commits
-
-
Hans Wennborg authored
llvm-svn: 326550
-
Hans Wennborg authored
llvm-svn: 326549
-
Chandler Carruth authored
llvm-svn: 326540
-
Chandler Carruth authored
llvm-svn: 326539
-
- 01 Mar, 2018 1 commit
-
-
Hans Wennborg authored
```--------------------------------------------------------------------- r326393 | ctopper | 2018-03-01 01:08:38 +0100 (Thu, 01 Mar 2018) | 5 lines [X86] Make sure we don't combine (fneg (fma X, Y, Z)) to a target specific node when there are no FMA instructions. This would cause a 'cannot select' error at isel when we should have emitted a lib call and an xor. Fixes PR36553. ``` --------------------------------------------------------------------- llvm-svn: 326423
-
- 28 Feb, 2018 2 commits
-
-
Martin Storsjo authored
llvm-svn: 326317
-
Richard Smith authored
llvm-svn: 326297
-
- 27 Feb, 2018 3 commits
-
-
Hans Wennborg authored
llvm-svn: 326200
-
Hans Wennborg authored
llvm-svn: 326199
-
Hans Wennborg authored
llvm-svn: 326197
-