summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [FastISel] Sink local value materializations to first useReid Kleckner2018-03-143-3/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Local values are constants, global addresses, and stack addresses that can't be folded into the instruction that uses them. For example, when storing the address of a global variable into memory, we need to materialize that address into a register. FastISel doesn't want to materialize any given local value more than once, so it generates all local value materialization code at EmitStartPt, which always dominates the current insertion point. This allows it to maintain a map of local value registers, and it knows that the local value area will always dominate the current insertion point. The downside is that local value instructions are always emitted without a source location. This is done to prevent jumpy line tables, but it means that the local value area will be considered part of the previous statement. Consider this C code: call1(); // line 1 ++global; // line 2 ++global; // line 3 call2(&global, &local); // line 4 Today we end up with assembly and line tables like this: .loc 1 1 callq call1 leaq global(%rip), %rdi leaq local(%rsp), %rsi .loc 1 2 addq $1, global(%rip) .loc 1 3 addq $1, global(%rip) .loc 1 4 callq call2 The LEA instructions in the local value area have no source location and are treated as being on line 1. Stepping through the code in a debugger and correlating it with the assembly won't make much sense, because these materializations are only required for line 4. This is actually problematic for the VS debugger "set next statement" feature, which effectively assumes that there are no registers live across statement boundaries. By sinking the local value code into the statement and fixing up the source location, we can make that feature work. This was filed as https://bugs.llvm.org/show_bug.cgi?id=35975 and https://crbug.com/793819. This change is obviously not enough to make this feature work reliably in all cases, but I felt that it was worth doing anyway because it usually generates smaller, more comprehensible -O0 code. I measured a 0.12% regression in code generation time with LLC on the sqlite3 amalgamation, so I think this is worth doing. There are some special cases worth calling out in the commit message: 1. local values materialized for phis 2. local values used by no-op casts 3. dead local value code Local values can be materialized for phis, and this does not show up as a vreg use in MachineRegisterInfo. In this case, if there are no other uses, this patch sinks the value to the first terminator, EH label, or the end of the BB if nothing else exists. Local values may also be used by no-op casts, which adds the register to the RegFixups table. Without reversing the RegFixups map direction, we don't have enough information to sink these instructions. Lastly, if the local value register has no other uses, we can delete it. This comes up when fastisel tries two instruction selection approaches and the first materializes the value but fails and the second succeeds without using the local value. Reviewers: aprantl, dblaikie, qcolombet, MatzeB, vsk, echristo Subscribers: dotdash, chandlerc, hans, sdardis, amccarth, javed.absar, zturner, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D43093 llvm-svn: 327581
* [CodeGen] Use MIR syntax for MachineMemOperand printingFrancis Visoiu Mistrih2018-03-144-271/+211
| | | | | | | | | | Get rid of the "; mem:" suffix and use the one we use in MIR: ":: (load 2)". rdar://38163529 Differential Revision: https://reviews.llvm.org/D42377 llvm-svn: 327580
* [EarlyCSE] Exploit open ended invariant.start scopesPhilip Reames2018-03-141-19/+75
| | | | | | | | | | | | If we have an invariant.start with no corresponding invariant.end, then the memory location becomes invariant indefinitely after the invariant.start. As a result, anything dominated by the start is guaranteed to see the value the memory location had when the invariant.start executed. This patch adds an AvailableInvariants table which tracks the generation a particular memory location became invariant and then uses that information to allow value forwarding that would otherwise be disallowed by potentially aliasing stores. (Reminder: In EarlyCSE everything clobbers everything by default.) This should be compatible with the MemorySSA variant, but design is generational. We can and should add first class support for invariant.start within MemorySSA at a later time. I took a quick look at doing so, but probably need some input from a MemorySSA expert. Differential Revision: https://reviews.llvm.org/D43716 llvm-svn: 327577
* Revert "[ORC] Switch from shared_ptr to unique_ptr for addModule methods."Reid Kleckner2018-03-144-26/+40
| | | | | | | | | | | | | This reverts commit r327566, it breaks test/ExecutionEngine/OrcMCJIT/test-global-ctors.ll. The test doesn't crash with a stack trace, unfortunately. It merely returns 1 as the exit code. ASan didn't produce a report, and I reproduced this on my Linux machine and Windows box. llvm-svn: 327576
* [InstSimplify] fix folds for (0.0 - X) + X --> 0 (PR27151)Sanjay Patel2018-03-141-14/+10
| | | | | | | | | | | | | | | | As shown in: https://bugs.llvm.org/show_bug.cgi?id=27151 ...the existing fold could miscompile when X is NaN. The fold was also dependent on 'ninf' but that's not necessary. From IEEE-754 (with default rounding which we can assume for these opcodes): "When the sum of two operands with opposite signs (or the difference of two operands with like signs) is exactly zero, the sign of that sum (or difference) shall be +0...However, x + x = x − (−x) retains the same sign as x even when x is zero." llvm-svn: 327575
* [AArch64] Emit CSR loads in the same order as storesFrancis Visoiu Mistrih2018-03-141-14/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Optionally allow the order of restoring the callee-saved registers in the epilogue to be reversed. The flag -reverse-csr-restore-seq generates the following code: ``` stp x26, x25, [sp, #-64]! stp x24, x23, [sp, #16] stp x22, x21, [sp, #32] stp x20, x19, [sp, #48] ; [..] ldp x24, x23, [sp, #16] ldp x22, x21, [sp, #32] ldp x20, x19, [sp, #48] ldp x26, x25, [sp], #64 ret ``` Note how the CSRs are restored in the same order as they are saved. One exception to this rule is the last `ldp`, which allows us to merge the stack adjustment and the ldp into a post-index ldp. This is done by first generating: ldp x26, x27, [sp] add sp, sp, #64 which gets merged by the arm64 load store optimizer into ldp x26, x25, [sp], #64 The flag is disabled by default. llvm-svn: 327569
* [ORC] Switch from shared_ptr to unique_ptr for addModule methods.Lang Hames2018-03-144-40/+26
| | | | | | | Layer implementations typically mutate module state, and this is better reflected by having layers own the Module they are operating on. llvm-svn: 327566
* [MC] Always emit relocations for same-section function referencesReid Kleckner2018-03-141-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We already emit relocations in this case when the "incremental linker compatible" flag is set, but it turns out these relocations are also required for /guard:cf. Now that we have two use cases for this behavior, let's make it unconditional to try to keep things simple. We never hit this problem in Clang because it always sets the "incremental linker compatible" flag when targeting MSVC. However, LLD LTO doesn't set this flag, so we'd get CFG failures at runtime when using ThinLTO and /guard:cf. We probably don't want LLD LTO to set the "incremental linker compatible" assembler flag, since this has nothing to do with incremental linking, and we don't need to timestamp LTO temporary objects. Fixes PR36624. Reviewers: inglorion, espindola, majnemer Subscribers: mehdi_amini, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D44485 llvm-svn: 327557
* [LLVM-C] [bindings/go] Add C and Golang bindings for COMDATReid Kleckner2018-03-141-2/+56
| | | | | | | | Patch by Ben Clayton Differential Revision: https://reviews.llvm.org/D44086 llvm-svn: 327551
* [X86] Add back fast-isel code for handling i8 shifts.Craig Topper2018-03-141-7/+14
| | | | | | | | | | I removed this in r316797 because the coverage report showed no coverage and I thought it should have been handled by the auto generated table. I now see that there is code that bypasses the table if the shift amount is out of bounds. This adds back the code. We'll codegen out of bounds i8 shifts to effectively (amount & 0x1f). The 0x1f is a strange quirk of x86 that shift amounts are always masked to 5-bits(except 64-bits). So if the masked value is still out bounds the result will be 0. Fixes PR36731. llvm-svn: 327540
* [AArch64] Keep track of MIFlags in the LoadStoreOptimizerFrancis Visoiu Mistrih2018-03-142-7/+20
| | | | | | | | | | | | | | | | Merging: * $x26, $x25 = frame-setup LDPXi $sp, 0 * $sp = frame-destroy ADDXri $sp, 64, 0 into an LDPXpost should preserve the flags from both instructions as following: * frame-setup frame-destroy LDPXpost Differential Revision: https://reviews.llvm.org/D44446 llvm-svn: 327533
* [X86] Teach X86TargetLowering::targetShrinkDemandedConstant to set ↵Craig Topper2018-03-142-5/+19
| | | | | | | | | | | | non-demanded bits if it helps created an and mask that can be matched as a zero extend. I had to modify the bswap recognition to allow unshrunk masks to make this work. Fixes PR36689. Differential Revision: https://reviews.llvm.org/D44442 llvm-svn: 327530
* [X86][AVX] Use WriteFShuffleLd for broadcast reg-mem instructionsSimon Pilgrim2018-03-141-4/+5
| | | | | | | | They shouldn't be treated as pure loads. Found while investigating D44428 llvm-svn: 327524
* [WebAssembly] Identify COMDATs by index rather than string. NFCNicholas Wilson2018-03-141-6/+11
| | | | | | | | This will enable an optimisation in LLD. Differential Revision: https://reviews.llvm.org/D44343 llvm-svn: 327522
* SjLjEHPrepare: Don't reg-to-mem swifterror valuesArnold Schwaighofer2018-03-141-22/+7
| | | | | | | | | | | | | | | | | swifterror llvm values model the swifterror register as memory at the LLVM IR level. ISel will perform adhoc mem-to-reg on them. swifterror values are constraint in how they can be used. Spilling them to memory is not allowed. SjLjEHPrepare tried to lower swifterror values to memory which is unecessary since the back-end will spill and reload the register as neccessary (as long as clobbering calls are marked as such which is the case here) and further leads to invalid IR because swifterror values can't be stored to memory. rdar://38164004 llvm-svn: 327521
* [GlobalIsel][X86] Support for G_SDIV instructionAlexander Ivchenko2018-03-142-4/+88
| | | | | | | | Reviewed By: igorb Differential Revision: https://reviews.llvm.org/D44430 llvm-svn: 327520
* [CodeGen] allow printing of zero latency in sched commentsSanjay Patel2018-03-141-5/+3
| | | | | | | | | | I don't know how to expose this in a test. There are ARM / AArch64 sched classes that include zero latency instructions, but I'm not seeing sched info printed for those targets. X86 will almost certainly have these soon (see PR36671), but no model has 'let Latency = 0' currently. llvm-svn: 327518
* [mips] Add support for CRC ASEPetar Jovanovic2018-03-1413-2/+216
| | | | | | | | | | | | | | | | | | | This includes Instructions: crc32b, crc32h, crc32w, crc32d, crc32cb, crc32ch, crc32cw, crc32cd Assembler directives: .set crc, .set nocrc, .module crc, .module nocrc Attribute: crc .MIPS.abiflags: CRC (0x8000) Patch by Vladimir Stefanovic. Differential Revision: https://reviews.llvm.org/D44176 llvm-svn: 327511
* [X86][Btver2] Fix YMM shuffle, permute and permutevar scheduler costsSimon Pilgrim2018-03-141-0/+57
| | | | | | Account for ymm double pumping and add proper pshufb/permutevar support llvm-svn: 327510
* [X86][SSE] Use WriteFShuffleLd for MOVDDUP/MOVSHDUP/MOVSLDUP reg-mem ↵Simon Pilgrim2018-03-141-4/+5
| | | | | | | | | | instructions They shouldn't be treated as pure loads. Found while investigating D44428 llvm-svn: 327505
* [AArch64] Don't produce R_AARCH64_TLSLE_LDST32_TPREL_LO12_NCMartin Storsjo2018-03-141-2/+7
| | | | | | | | | Support for this relocation is missing in both LLD and GNU binutils at the moment. This reverts the ELF parts of SVN r327316. llvm-svn: 327503
* Fix 'not all control paths return a value' MSVC warning. NFCI.Simon Pilgrim2018-03-141-0/+1
| | | | llvm-svn: 327502
* Fix msvc compiler error in r327498Pavel Labath2018-03-141-1/+1
| | | | | | | msvc reports an "illegal indirection" error here. Attempt to appease it with a different initialization syntax. llvm-svn: 327500
* [GlobalISel][X86] Support G_LSHR/G_ASHR/G_SHLAlexander Ivchenko2018-03-143-0/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support G_LSHR/G_ASHR/G_SHL. We have 3 variance for shift instructions : shift gpr, shift imm, shift 1. Currently GlobalIsel TableGen generate patterns for shift imm and shift 1, but with shiftCount i8. In G_LSHR/G_ASHR/G_SHL like LLVM-IR both arguments has the same type, so for now only shift i8 can use auto generated TableGen patterns. The support of G_SHL/G_ASHR enables tryCombineSExt from LegalizationArtifactCombiner.h to hit, which results in different legalization for the following tests: LLVM :: CodeGen/X86/GlobalISel/ext-x86-64.ll LLVM :: CodeGen/X86/GlobalISel/gep.ll LLVM :: CodeGen/X86/GlobalISel/legalize-ext-x86-64.mir -; X64-NEXT: movsbl %dil, %eax +; X64-NEXT: movl $24, %ecx +; X64-NEXT: # kill: def $cl killed $ecx +; X64-NEXT: shll %cl, %edi +; X64-NEXT: movl $24, %ecx +; X64-NEXT: # kill: def $cl killed $ecx +; X64-NEXT: sarl %cl, %edi +; X64-NEXT: movl %edi, %eax ..which is not optimal and should be addressed later. Rework of the patch by igorb Reviewed By: igorb Differential Revision: https://reviews.llvm.org/D44395 llvm-svn: 327499
* Explicitly initialize dwarf::FormParams in DIEInteger::SizeOfPavel Labath2018-03-141-1/+1
| | | | | | | | | | | | | | | | | This could end up inititialized if someone called the function with a null AsmPrinter. Right now this only happens in DIEHash unit tests, presumably because it was hard to create an AsmPrinter in the context of unit tests. This only worked before r327486 because those tests did not use any dwarf forms whose size actually depended on the dwarf version (otherwise, they would have crashed due to null dereference). I fix the uninitialized error, by explicitly initializing FormParams to an invalid value, which will cause getFixedFormByteSize to return None if called with a form with version-dependent size. A more principled solution might be to fix the DIEHash tests to always pass in a valid AsmPrinter. llvm-svn: 327498
* TableGen: Explicitly forbid some nestings of class, multiclass, and foreachNicolai Haehnle2018-03-141-2/+10
| | | | | | | | | | | These previously all failed one way or another, but now we produce a more helpful error message. Change-Id: I8ffd2e87c8e35a5134c3be289e0a1fecaa2bb8ca Differential revision: https://reviews.llvm.org/D44115 llvm-svn: 327497
* TableGen: Add !ne, !le, !lt, !ge, and !gt comparisonsNicolai Haehnle2018-03-144-11/+66
| | | | | | | | Change-Id: I8e2ece677268972d578a787467f7ef52a1f33a71 Differential revision: https://reviews.llvm.org/D44114 llvm-svn: 327496
* TableGen: Allow dag operators to be resolved lateNicolai Haehnle2018-03-141-2/+7
| | | | | | | | Change-Id: I51bb80fd5c48c8ac441ab11e43d43c1b91b4b590 Differential revision: https://reviews.llvm.org/D44113 llvm-svn: 327495
* TableGen: Type-check BinOpsNicolai Haehnle2018-03-141-30/+92
| | | | | | | | | | | Additionally, allow more than two operands to !con, !add, !and, !or in the same way as is already allowed for !listconcat and !strconcat. Change-Id: I9659411f554201b90cd8ed7c7e004d381a66fa93 Differential revision: https://reviews.llvm.org/D44112 llvm-svn: 327494
* TableGen: Allow ? in listsNicolai Haehnle2018-03-141-11/+9
| | | | | | | | | | This makes using !dag more convenient in some cases. Change-Id: I0a8c35e15ccd1ecec778fd1c8d64eee38d74517c Differential revision: https://reviews.llvm.org/D44111 llvm-svn: 327493
* TableGen: Add !dag function for constructionNicolai Haehnle2018-03-144-1/+66
| | | | | | | | | | | | | | | This allows constructing DAG nodes with programmatically determined names, and can simplify constructing DAG nodes in other cases as well. Also, add documentation and some very simple tests for the already existing !con. Change-Id: Ida61cd82e99752548d7109ce8da34d29da56a5f7 Differential revision: https://reviews.llvm.org/D44110 llvm-svn: 327492
* DWARF: Unify form size handling codePavel Labath2018-03-147-150/+109
| | | | | | | | | | | | | | | | | Summary: This patch replaces the two switches which are deducing the size of various forms with a single implementation. I have put the new implementation into BinaryFormat, to avoid introducing dependencies between the two independent libraries (DebugInfo and CodeGen) that need this functionality. Reviewers: aprantl, JDevlieghere, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44418 llvm-svn: 327486
* [GlobalIsel][X86] Support for G_ZEXT instructionAlexander Ivchenko2018-03-141-0/+64
| | | | | | | | Reviewed By: igorb Differential Revision: https://reviews.llvm.org/D44378 llvm-svn: 327482
* [LLVM-C] Redo unnamed_address attribute bindingsRobert Widmann2018-03-141-0/+24
| | | | | | | | | | | | | | | | | | | Summary: The old bindings should have used an enum instead of a boolean. This deprecates LLVMHasUnnamedAddr and LLVMSetUnnamedAddr , replacing them with LLVMGetUnnamedAddress and LLVMSetUnnamedAddress respectively that do. Though it is unlikely LLVM will gain more supported global value linker hints, the new API can scale to accommodate this. Reviewers: deadalnix, whitequark Reviewed By: whitequark Subscribers: llvm-commits, harlanhaskins Differential Revision: https://reviews.llvm.org/D43448 llvm-svn: 327479
* [RuntimeDyld] Silence a compiler error.Lang Hames2018-03-141-1/+1
| | | | | | | This should fix the error at http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/19008 llvm-svn: 327478
* [ORC] Fix a data race in the lookup function.Lang Hames2018-03-141-10/+24
| | | | | | | | | | | The Error locals need to be protected by a mutex. (This could be fixed by having the promises / futures contain Expected and Error values, but MSVC's future implementation does not support this yet). Hopefully this will fix some of the errors seen on the builders due to r327474. llvm-svn: 327477
* [ExecutionEngine] Add a getSymbolTable method to RuntimeDyld.Lang Hames2018-03-142-0/+21
| | | | | | | | | | This can be used to extract the symbol table from a RuntimeDyld instance prior to disposing of it. This patch also updates RTDyldObjectLinkingLayer to use the new method, rather than requesting symbols one at a time via getSymbol. llvm-svn: 327476
* [ORC] Silence a compiler error.Lang Hames2018-03-141-1/+1
| | | | | | | This should fix the builder error at http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/19006 llvm-svn: 327475
* [ORC] Add a 'lookup' convenience function for finding symbols in a list of VSOs.Lang Hames2018-03-141-0/+118
| | | | | | | | | | | | | | The lookup function takes a list of VSOs, a set of symbol names (or just one symbol name) and a materialization function object. It returns an Expected<SymbolMap> (if given a set of names) or an Expected<JITEvaluatedSymbol> (if given just one name). The lookup method constructs an AsynchronousSymbolQuery for the given names, applies that query to each VSO in the list in turn, and then blocks waiting for the query to complete. If threading is enabled then the materialization function object can be used to execute the materialization on different threads. If threading is disabled the MaterializeOnCurrentThread utility must be used. llvm-svn: 327474
* TargetMachine: Add address space to getPointerSizeMatt Arsenault2018-03-148-13/+15
| | | | llvm-svn: 327467
* [X86] Simplify the LowerAVXCONCAT_VECTORS code a little by creating a single ↵Craig Topper2018-03-131-21/+18
| | | | | | | | path for insert_subvector handling. We now only create recursive concats if we have more than two non-zero values. This keeps our subvector broadcast DAG combine functioning. llvm-svn: 327457
* [X86] Rewrite LowerAVXCONCAT_VECTORS similar to how we handle vXi1 concats.Craig Topper2018-03-132-51/+53
| | | | | | | | | | This better able to detect undef and zeros pieces in the concat. Or cases when only one subvector is non-zero. This allows us to avoid silly things like double inserts into progressively larger undefs. This still builds 512 bit concats of 128 bits by building up through 256 bits first. But I don't know if that's best. We probably want to merge this with the vXi1 concat code since they are very similar. llvm-svn: 327454
* Simplify more cases of logical ops of masked icmps.Hiroshi Yamauchi2018-03-131-17/+199
| | | | | | | | | | | | | | | | | | Summary: For example, ((X & 255) != 0) && ((X & 15) == 8) -> ((X & 15) == 8). ((X & 7) != 0) && ((X & 15) == 8) -> false. Reviewers: davidxl Reviewed By: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43835 llvm-svn: 327450
* [DAGCombiner] Allow visitEXTRACT_SUBVECTOR to combine with BUILD_VECTORS ↵Craig Topper2018-03-131-1/+1
| | | | | | | | between LegalizeVectorOps and LegalizeDAG. BUILD_VECTORs aren't themselves legalized until LegalizeDAG so we should still be able to create an "illegal" one before that. This helps combine with BUILD_VECTORS that are introduced during LegalizeVectorOps due to unrolling. llvm-svn: 327446
* [MIR] Allow frame-setup and frame-destroy on the same instructionFrancis Visoiu Mistrih2018-03-133-7/+9
| | | | | | | | | | | | | | | Nothing prevents us from having both frame-setup and frame-destroy on the same instruction. When merging: * frame-setup OPCODE1 * frame-destroy OPCODE2 into * frame-setup frame-destroy OPCODE3 we want to be able to print and parse both flags. llvm-svn: 327442
* Test Commit NFC. Updated commentAnna Thomas2018-03-131-1/+1
| | | | llvm-svn: 327436
* [SLP] clean some formatsHaicheng Wu2018-03-131-3/+3
| | | | llvm-svn: 327433
* [LazyValueInfo] PR33357 prevent infinite recursion on BinaryOperatorBrian M. Rzycki2018-03-131-3/+11
| | | | | | | | | | | | | | | | | | | | | | Summary: It is possible for LVI to encounter instructions that are not in valid SSA form and reference themselves. One example is the following: %tmp4 = and i1 %tmp4, undef Before this patch LVI would recurse until running out of stack memory and crashed. This patch marks these self-referential instructions as Overdefined and aborts analysis on the instruction. Fixes https://bugs.llvm.org/show_bug.cgi?id=33357 Reviewers: craig.topper, anna, efriedma, dberlin, sebpop, kuhar Reviewed by: dberlin Subscribers: uabelho, spatel, a.elovikov, fhahn, eli.friedman, mzolotukhin, spop, evandro, davide, llvm-commits Differential Revision: https://reviews.llvm.org/D34135 llvm-svn: 327432
* Handle mixed-OS paths in DWARF readerEugene Zemtsov2018-03-131-2/+10
| | | | | | | | Make sure that DWARF line information generated by Windows can be properly read by Posix OS and vice versa. Differential Revision: https://reviews.llvm.org/D44290 llvm-svn: 327430
* [MC] fix documentation comments; NFCSanjay Patel2018-03-131-25/+14
| | | | llvm-svn: 327429
OpenPOWER on IntegriCloud