summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Have the selection dag grab TargetLowering off of the subtargetEric Christopher2014-10-082-4/+3
| | | | | | inside init rather than have it passed in as an argument. llvm-svn: 219270
* Revert r219175 - [InstCombine] re-commit r218721 icmp-select-icmp optimizationHans Wennborg2014-10-083-151/+8
| | | | | | This seems to have caused PR21199. llvm-svn: 219264
* Have SelectionDAG's subtarget TargetSelectionDAGInfo be setEric Christopher2014-10-081-2/+2
| | | | | | during init rather than construction time. llvm-svn: 219262
* [DebugInfo] Pass DWARFSection down to DWARFUnit constructor (NFC).Alexey Samsonov2014-10-084-25/+25
| | | | | | Keep the actual section contents and the relocation map together. llvm-svn: 219261
* [Support] Add MemoryBuffer::getFileSlice()Nick Kledzik2014-10-081-8/+15
| | | | | | | | | | mach-o supports "fat" files which are a header/table-of-contents followed by a concatenation of mach-o files built for different architectures. Currently, MemoryBuffer has no easy way to map a subrange (slice) of a file which lld will need to select a mach-o slice of a fat file. The new function provides an easy way to map a slice of a file into a MemoryBuffer. Test case included. llvm-svn: 219260
* [DebugInfo] Pass DWARFSection into DWARFUnitSection constructor (NFC).Alexey Samsonov2014-10-083-27/+25
| | | | llvm-svn: 219259
* [X86] Fix a bug with fetch_add(INT32_MIN)Robin Morisset2014-10-071-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fix pr21099 The pseudocode of what we were doing (spread through two functions) was: if (operand.doesNotFitIn32Bits()) Opc.initializeWithFoo(); if (operand < 0) operand = -operand; if (operand.doesFitIn8Bits()) Opc.initializeWithBar(); else if (operand.doesFitIn32Bits()) Opc.initializeWithBlah(); doStuff(Opc); So for operand == INT32_MIN, Opc was never initialized because the operand changes from fitting in 32 bits to not fitting, causing the various bugs/error messages noted by pr21099. This patch adds an extra test at the beginning for this case, and an llvm_unreachable to have better error message if the operand ends up not fitting in 32-bits at the end. Test Plan: new test + make check Reviewers: jfb Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5655 llvm-svn: 219257
* R600/SI: Refactor VOP3 instruction defsTom Stellard2014-10-072-61/+64
| | | | llvm-svn: 219256
* R600/SI: Refactor VOPC instruction defsTom Stellard2014-10-072-213/+217
| | | | llvm-svn: 219255
* R600/SI: Refactor VOP2 instruction defsTom Stellard2014-10-072-42/+46
| | | | llvm-svn: 219254
* R600/SI: Refactor VOP1 instruction defsTom Stellard2014-10-073-72/+96
| | | | llvm-svn: 219253
* [DebugInfo] Turn DWARFContext::Section into DWARFSection (NFC).Alexey Samsonov2014-10-072-25/+45
| | | | | | | | It would be more convenient to pass DWARFSection into DWARFUnitSection constructor, instead of passing its components (Data and RelocAddrMap) as a separate arguments. llvm-svn: 219252
* DebugInfo+DFSan: Ensure that debug info references to llvm::Functions remain ↵David Blaikie2014-10-071-0/+10
| | | | | | | | | | | | | | | | | | | | | | pointing to the underlying function when wrappers are created This is somewhat the inverse of how similar bugs in DAE and ArgPromo manifested and were addressed. In those passes, individual call sites were visited explicitly, and then the old function was deleted. This left the debug info with a null llvm::Function* that needed to be updated to point to the new function. In the case of DFSan, it RAUWs the old function with the wrapper, which includes debug info. So now the debug info refers to the wrapper, which doesn't actually have any instructions with debug info in it, so it is ignored entirely - resulting in a DW_TAG_subprogram with no high/low pc, etc. Instead, fix up the debug info to refer to the original function after the RAUW messed it up. Reviewed/discussed with Peter Collingbourne on the llvm-dev mailing list. llvm-svn: 219249
* R600: Remove dead codeMatt Arsenault2014-10-072-18/+1
| | | | llvm-svn: 219242
* LoopUnroll: Create sub-loops in LoopInfoDuncan P. N. Exon Smith2014-10-071-1/+29
| | | | | | | | | | | | | `LoopUnrollPass` says that it preserves `LoopInfo` -- make it so. In particular, tell `LoopInfo` about copies of inner loops when unrolling the outer loop. Conservatively, also tell `ScalarEvolution` to forget about the original versions of these loops, since their inputs may have changed. Fixes PR20987. llvm-svn: 219241
* LoopUnroll: Only check for ScalarEvolution analysis once, NFCDuncan P. N. Exon Smith2014-10-071-7/+4
| | | | | | | A follow-up commit will add use to a tight loop. We might as well just find it once anyway. llvm-svn: 219239
* R600: Remove some redundant initializations from AMDGPUMCAsmInfoTom Stellard2014-10-071-10/+0
| | | | llvm-svn: 219238
* R600: Use MCAsmInfoELF as AMDGPUMCAsmInfo base classTom Stellard2014-10-072-3/+8
| | | | | | | | | | | | | The main reason for this is that the MCAsmInfo class, which we were previously using as the base class, sets PrivateGlobalPrefix to "L", which causes all global functions that start with L to be treated as local symbols. MCAsmInfoELF sets PrivateGlobalPrefix to ".L", which is what we want, and it is probably a good idea to use this as the base class anyway, since we are emitting ELF binaries. llvm-svn: 219237
* R600/SI: Remove assertion in SIInstrInfo::areLoadsFromSameBasePtr()Tom Stellard2014-10-071-1/+4
| | | | | | | Added a FIXME coment instead, we need to handle the case where the two DS instructions being compared have different numbers of operands. llvm-svn: 219236
* Don't check for null after calling COFFObjectFile::toSec.Rafael Espindola2014-10-071-2/+0
| | | | | | | | | | | It can only return null if passed a corrupted reference with a null Ref.p. Checking for null is then an issue for asserts to check for internal consistency, not control flow to check for invalid input. I didn't add an assert(sec != nullptr) because toSec itself has a far more complete assert. llvm-svn: 219235
* Optimize COFFObjectFile::sectionContainsSymbol a bit.Rafael Espindola2014-10-071-7/+2
| | | | | | | | | There is no need to compute the coff_section of the symbol just to compare the pointer. Inspired by the ELF implementation. llvm-svn: 219233
* MC: add support for -aligncomm GNU extensionSaleem Abdulrasool2014-10-071-8/+18
| | | | | | | The GNU linker supports an -aligncomm directive that allows for power-of-2 alignment of common data. Add support to emit this directive. llvm-svn: 219229
* Remove the IsVolatileSize parameter of getOpenFileSlice.Rafael Espindola2014-10-071-2/+3
| | | | | | | getOpenFileSlice gets passed the map size, so it makes no sense to say that the size is volatile. The code will not even compute the size. llvm-svn: 219226
* Be consistent about using "const Twine &" for filenames.Rafael Espindola2014-10-071-22/+27
| | | | | | | | | | | | | | | On this file we had a mix of * Twine * const char * * StringRef The two that make sense are * const Twine & (caller convenience) * consc char * (that is what will eventually be passed to open. Given that sys::fs::openFileForRead takes a "const Twine &", I picked that. llvm-svn: 219224
* Two case switch to select optimizationMarcello Maggioni2014-10-071-0/+170
| | | | | | | | | | | | | | | | | | | | | This optimization tries to convert switch instructions that are used to select a value with only 2 unique cases + default block to a select or a couple of selects (depending if the default block is reachable or not). The typical case this optimization wants to be able to optimize is this one: Example: switch (a) { case 10: %0 = icmp eq i32 %a, 10 return 10; %1 = select i1 %0, i32 10, i32 4 case 20: ----> %2 = icmp eq i32 %a, 20 return 2; %3 = select i1 %2, i32 2, i32 %1 default: return 4; } It also sets the base for further optimizations that are planned and being reviewed. llvm-svn: 219223
* typosSanjay Patel2014-10-071-2/+2
| | | | llvm-svn: 219221
* typosSanjay Patel2014-10-071-1/+1
| | | | llvm-svn: 219220
* DebugInfo: Ensure that all debug location scope chains from instructions ↵David Blaikie2014-10-072-2/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | within a function, lead to the function itself. Let me tell you a tale... Originally committed in r211723 after discovering a nasty case of weird scoping due to inlining, this was reverted in r211724 after it fired in ASan/compiler-rt. (minor diversion where I accidentally committed/reverted again in r211871/r211873) After further testing and fixing bugs in ArgumentPromotion (r211872) and Inlining (r212065) it was recommitted in r212085. Reverted in r212089 after the sanitizer buildbots still showed problems. Fixed another bug in ArgumentPromotion (r212128) found by this assertion. Recommitted in r212205, reverted in r212226 after it crashed some more on sanitizer buildbots. Fix clang some more in r212761. Recommitted in r212776, reverted in r212793. ASan failures. Recommitted in r213391, reverted in r213432, trying to reproduce flakey ASan build failure. Fixed bugs in r213805 (ArgPromo + DebugInfo), r213952 (LiveDebugVariables strips dbg_value intrinsics in functions not described by debug info). Recommitted in r214761, reverted in r214999, flakey failure on Windows buildbot. Fixed DeadArgElimination + DebugInfo bug in r219210. Recommitting and hoping that's the last of it. [That one burned down, fell over, then sank into the swamp.] llvm-svn: 219215
* DebugInfo+DeadArgElimination: Ensure llvm::Function*s from debug info are ↵David Blaikie2014-10-072-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | updated even when DAE removes both varargs and non-varargs arguments on the same function. After some stellar (& inspired) help from Reid Kleckner providing a test case for some rather unstable undefined behavior showing up as assertions produced by r214761, I was able to fix this issue in DAE involving the application of both varargs removal, followed by normal argument removal. Indeed I introduced this same bug into ArgumentPromotion (r212128) by copying the code from DAE, and when I fixed the bug in ArgPromo (r213805) and commented in that patch that I didn't need to address the same issue in DAE because it was a single pass. Turns out it's two pass, one for the varargs and one for the normal arguments, so the same fix is needed (at least during varargs removal). So here it is. (the observable/net effect of this bug, even when it didn't result in assertion failure, is that debug info would describe the DAE'd function in the abstract, but wouldn't provide high/low_pc, variable locations, line table, etc (it would appear as though the function had been entirely optimized away), see the original PR14016 for details of the general problem) I'm not recommitting the assertion just yet, as there's been another regression of it since I last tried. It might just be a few test cases weren't adequately updated after Adrian or Duncan's recent schema changes. llvm-svn: 219210
* Reformat if statement to comply with LLVM standards. NFC.Suyog Sarda2014-10-071-2/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D5644 llvm-svn: 219203
* Reformat to comply with LLVM coding standards using clang-format.Suyog Sarda2014-10-071-5/+4
| | | | | | | | NFC. Differential Revision: http://reviews.llvm.org/D5645 llvm-svn: 219202
* [asan-asm-instrumentation] CFI directives are generated for .S files.Yuri Gorshenin2014-10-074-10/+63
| | | | | | | | | | | | Summary: CFI directives are generated for .S files. Reviewers: eugenis Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5520 llvm-svn: 219199
* [InstCombine] Reformat if statements to comply with LLVM Coding Standards.Tilmann Scheller2014-10-071-2/+6
| | | | | | | | Patch by Sonam Kumari! Differential Revision: http://reviews.llvm.org/D5643 llvm-svn: 219198
* [mips] Return {f128} correctly for N32/N64.Daniel Sanders2014-10-072-2/+12
| | | | | | | | | | | | | | | | | Summary: According to the ABI documentation, f128 and {f128} should both be returned in $f0 and $f2. However, this doesn't match GCC's behaviour which is to return f128 in $f0 and $f2, but {f128} in $f0 and $f1. Reviewers: vmedic Reviewed By: vmedic Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5578 llvm-svn: 219196
* [X86] Fix a bug where the disassembler was ignoring the VEX.W bit in 32-bit ↵Craig Topper2014-10-071-0/+47
| | | | | | | | | | mode for certain instructions it shouldn't. Unfortunately, this isn't easy to fix since there's no simple way to figure out from the disassembler tables whether the W-bit is being used to select a 64-bit GPR or if its a required part of the opcode. The fix implemented here just looks for "64" in the instruction name and ignores the W-bit in 32-bit mode if its present. Fixes PR21169. llvm-svn: 219194
* Formatting fixes. Most putting 'else' on the same line as the preceding ↵Craig Topper2014-10-071-38/+19
| | | | | | curly brace. llvm-svn: 219193
* Fix filename in header and use C++ version of the C header files.Craig Topper2014-10-071-5/+5
| | | | llvm-svn: 219192
* GlobalDCE: Don't drop any COMDAT membersDavid Majnemer2014-10-071-25/+14
| | | | | | | | | If we require a single member of a comdat, require all of the other members as well. This fixes PR20981. llvm-svn: 219191
* Attempt to calm down buildbotsDavid Majnemer2014-10-071-0/+3
| | | | llvm-svn: 219190
* Support: Don't call close again if we get EINTRDavid Majnemer2014-10-073-11/+34
| | | | | | | | | | | | | | | | | | | | | | | | | Most Unix-like operating systems guarantee that the file descriptor is closed after a call to close(2), even if close comes back with EINTR. For these systems, calling close _again_ will either do nothing or close some other file descriptor open(2)'d by another thread. (Linux) However, some operating systems do not have this behavior. They require at least another call to close(2) before guaranteeing that the descriptor is closed. (HP-UX) And some operating systems have an unpredictable blend of the two behaviors! (xnu) Avoid this disaster by blocking all signals before we call close(2). This ensures that a signal will not be delivered to the thread and close(2) will not give us back EINTR. We restore the signal mask once the operation is done. N.B. This isn't a problem on Windows, it doesn't have a notion of EINTR because signals always get delivered to dedicated signal handling threads. llvm-svn: 219189
* [FastISel][AArch64] Teach the address computation code to also fold ↵Juergen Ributzka2014-10-071-0/+29
| | | | | | | | | | sign-/zero-extends. The code already folds sign-/zero-extends, but only if they are arguments to mul and shift instructions. This extends the code to also fold them when they are direct inputs. llvm-svn: 219187
* [FastISel][AArch64] Teach the address computation to also fold sub instructions.Juergen Ributzka2014-10-071-1/+12
| | | | | | | Tiny enhancement to the address computation code to also fold sub instructions if the rhs is constant and can be folded into the offset. llvm-svn: 219186
* [FastISel][AArch64] Fix "Fold sign-/zero-extends into the load instruction."Juergen Ributzka2014-10-071-64/+90
| | | | | | | | | | This commit fixes an issue with sign-/zero-extending loads that was discovered by Richard Barton. We use now the correct load instructions for sign-extending loads to 64bit. Also updated and added more unit tests. llvm-svn: 219185
* [InstCombine] re-commit r218721 icmp-select-icmp optimizationGerolf Hoflehner2014-10-073-8/+151
| | | | | | | | | Takes care of the assert that caused build fails. Rather than asserting the code checks now that the definition and use are in the same block, and does not attempt to optimize when that is not the case. llvm-svn: 219175
* ARMInstPrinter.cpp: Suppress a warning for -Asserts. [-Wunused-variable]NAKAMURA Takumi2014-10-061-3/+2
| | | | llvm-svn: 219172
* Support: Add a utility to remap std{in,out,err} to /dev/null if closedDavid Majnemer2014-10-062-0/+63
| | | | | | | | | | | | | | | It's possible to start a program with one (or all) of the standard file descriptors closed. Subsequent open system calls will give the program a low-numbered file descriptor. This is problematic because we may believe we are writing to standard out instead of a file. Introduce Process::FixupStandardFileDescriptors, a helper function to remap standard file descriptors to /dev/null if they were closed before the program started. llvm-svn: 219170
* range-for some loops in DAEDavid Blaikie2014-10-061-6/+3
| | | | llvm-svn: 219167
* LoopUnroll: Change code order of changes to new basic blocksDuncan P. N. Exon Smith2014-10-061-2/+2
| | | | | | | Add new basic blocks to `LoopInfo` earlier. No functionality change intended (simplifies upcoming bugfix patch). llvm-svn: 219150
* Sink comment, NFCDuncan P. N. Exon Smith2014-10-061-2/+2
| | | | llvm-svn: 219149
* [DAGCombine] Remove SIGN_EXTEND-related inf-loopHal Finkel2014-10-061-6/+2
| | | | | | | | | | | | | | | | | | | | | | The patch's author points out that, despite the function's documentation, getSetCCResultType is only used to get the SETCC result type (with one here-removed problematic exception). In one case, getSetCCResultType was being used to get the predicate type to use for a SELECT node, and then SIGN_EXTENDing (or truncating) to get the input predicate to match that type. Unfortunately, this was happening inside visitSIGN_EXTEND, and creating new SIGN_EXTEND nodes was causing an infinite loop. In addition, this behavior was wrong if a target was not using ZeroOrNegativeOneBooleanContent. Lastly, the extension/truncation seems unnecessary here: SELECT is defined as: Select(COND, TRUEVAL, FALSEVAL). If the type of the boolean COND is not i1 then the high bits must conform to getBooleanContents. So here we remove this use of getSetCCResultType and update getSetCCResultType's documentation to reflect its actual uses. Patch by deadal nix! llvm-svn: 219141
OpenPOWER on IntegriCloud