summaryrefslogtreecommitdiffstats
path: root/llvm
Commit message (Collapse)AuthorAgeFilesLines
...
* [WebAssembly] Use the new offset syntax for memory operands in inline asm.Dan Gohman2015-12-162-2/+4
| | | | llvm-svn: 255788
* [SystemZ] Sort relocs to avoid code corruption by linker optimizationUlrich Weigand2015-12-162-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SystemZ linkers provide an optimization to transform a general- or local-dynamic TLS sequence into an initial-exec sequence if possible. Do do that, the compiler generates a function call to __tls_get_offset, which is a brasl instruction annotated with *two* relocations: - a R_390_PLT32DBL to install __tls_get_offset as branch target - a R_390_TLS_GDCALL / R_390_TLS_LDCALL to inform the linker that the TLS optimization should be performed if possible If the optimization is performed, the brasl is replaced by an ld load instruction. However, *both* relocs are processed independently by the linker. Therefore it is crucial that the R_390_PLT32DBL is processed *first* (installing the branch target for the brasl) and the R_390_TLS_GDCALL is processed *second* (replacing the whole brasl with an ld). If the relocs are swapped, the linker will first replace the brasl with an ld, and *then* install the __tls_get_offset branch target offset. Since ld has a different layout than brasl, this may even result in a completely different (or invalid) instruction; in any case, the resulting code is corrupted. Unfortunately, the way the MC common code sorts relocations causes these two to *always* end up the wrong way around, resulting in wrong code generation by the linker and crashes. This patch overrides the sortRelocs routine to detect this particular pair of relocs and enforce the required order. llvm-svn: 255787
* [SystemZ] Fix assertion failure in adjustSubwordCmpUlrich Weigand2015-12-162-2/+26
| | | | | | | | | | | | | | | | | | | | When comparing a zero-extended value against a constant small enough to be in range of the inner type, it doesn't matter whether a signed or unsigned compare operation (for the outer type) is being used. This is why the code in adjustSubwordCmp had this assertion: assert(C.ICmpType == SystemZICMP::Any && "Signedness shouldn't matter here."); assuming the the caller had already detected that fact. However, it turns out that there cases, in particular with always-true or always- false conditions that have not been eliminated when compiling at -O0, where this is not true. Instead of failing an assertion if C.ICmpType is not SystemZICMP::Any here, we can simply *set* it safely to SystemZICMP::Any, however. llvm-svn: 255786
* [Hexagon] Make memcpy lowering thread-safeTobias Edler von Koch2015-12-164-21/+70
| | | | | | | | This removes an unpleasant hack involving a global variable for special lowering of certain memcpy calls. These are now lowered as intended in EmitTargetCodeForMemcpy in the same way that other targets do it. llvm-svn: 255785
* [NFC] Update horizontal reduction test cases.Charlie Turner2015-12-162-2/+2
| | | | | | | These testcases no longer need to specify -slp-vectorize-hor, since it was enabled by default in r252733. llvm-svn: 255783
* [WebAssembly] Support more kinds of inline asm operandsDan Gohman2015-12-162-4/+39
| | | | llvm-svn: 255782
* Install runtime dlls in the INSTALL_DIR/bin directory. NFCSumanth Gundapaneni2015-12-161-2/+4
| | | | | | | | | One of the earlier patches updated the cmake rule to install the runtime dlls in INSTALL_DIR/lib which is not correct. This patch updates the rule to install CMake's RUNTIME in bin directory Differential Revision: http://reviews.llvm.org/D15505 llvm-svn: 255781
* [Packetizer] Add a check whether an instruction should be packetized nowKrzysztof Parzyszek2015-12-162-2/+13
| | | | | | | | Add a function VLIWPacketizerList::shouldAddToPacket, which will allow specific implementations to decide if it is profitable to add given instruction to the current packet. llvm-svn: 255780
* Add RAII wrapper for gold plugin file managementTeresa Johnson2015-12-161-23/+31
| | | | | | Suggested in review of r255256. llvm-svn: 255779
* Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributesVaivaswatha Nagaraj2015-12-1619-14/+105
| | | | | | | | | | | | | | | | | | Summary: This patch introduces two new function attributes InaccessibleMemOnly: This attribute indicates that the function may only access memory that is not accessible by the program/IR being compiled. This is a weaker form of ReadNone. inaccessibleMemOrArgMemOnly: This attribute indicates that the function may only access memory that is either not accessible by the program/IR being compiled, or is pointed to by its pointer arguments. This is a weaker form of ArgMemOnly Test cases have been updated. This revision uses this (https://github.com/llvm-mirror/llvm/commit/d001932f3a8aa1ebd1555162fdce365f011bc292) as reference. Reviewers: jmolloy, hfinkel Subscribers: reames, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15499 llvm-svn: 255778
* [SimplifyCFG] Don't create unnecessary PHIsJames Molloy2015-12-162-0/+220
| | | | | | | | | | | | | | In conditional store merging, we were creating PHIs when we didn't need to. If the value to be predicated isn't defined in the block we're predicating, then it doesn't need a PHI at all (because we only deal with triangles and diamonds, any value not in the predicated BB must dominate the predicated BB). This fixes a large code size increase in some benchmarks in a popular embedded benchmark suite. Now with a fix (and fixed tests) for the conformance issue seen in Chromium. llvm-svn: 255767
* [ARM] Add ARMv8.2-A FP16 vector instructionsOliver Stannard2015-12-1610-42/+2289
| | | | | | | | | | | | | | ARMv8.2-A adds 16-bit floating point versions of all existing SIMD floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. Note that VFP without SIMD is not a valid combination for any version of ARMv8-A, but I have ensured that these instructions all depend on both FeatureNEON and FeatureFullFP16 for consistency. Differential Revision: http://reviews.llvm.org/D15039 llvm-svn: 255764
* [ARM] Add ARMv8.2-A FP16 scalar instructionsOliver Stannard2015-12-1618-6/+1976
| | | | | | | | | | | | | | | | | | | | | | | | | | | ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 255762
* [X86] Improve shift combiningMichael Kuperstein2015-12-165-853/+1103
| | | | | | | | | | | | | | | | | | | | This folds (ashr (shl a, [56,48,32,24,16]), SarConst) into (shl, (sext (a), [56,48,32,24,16] - SarConst)) or into (lshr, (sext (a), SarConst - [56,48,32,24,16])) depending on sign of (SarConst - [56,48,32,24,16]) sexts in X86 are MOVs. The MOVs have the same code size as above SHIFTs (only SHIFT by 1 has lower code size). However the MOVs have 2 advantages to SHIFTs on x86: 1. MOVs can write to a register that differs from source. 2. MOVs accept memory operands. This fixes PR24373. Patch by: evgeny.v.stupachenko@intel.com Differential Revision: http://reviews.llvm.org/D13161 llvm-svn: 255761
* [SectionMemoryManager] Make better use of virtual memoryKeno Fischer2015-12-163-44/+90
| | | | | | | | | | | | | | | | | Summary: On Windows, the allocation granularity can be significantly larger than a page (64K), so with many small objects, just clearing the FreeMem list rapidly leaks quite a bit of virtual memory space (if not rss). Fix that by only removing those parts of the FreeMem blocks that overlap pages for which we are applying memory permissions, rather than dropping the FreeMem blocks entirely. Reviewers: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15202 llvm-svn: 255760
* Recommit LiveDebugValues pass after fixing a couple of minor issues.Vikram TV2015-12-1614-5/+1135
| | | | llvm-svn: 255759
* Remove FileCheck from test case token_landingpad.ll. Chen Li2015-12-161-3/+2
| | | | | | The test case only needs to make sure it does not crash LLVM. llvm-svn: 255755
* Minor change to TailDuplication.cpp to turn on normalization when removing ↵Cong Hou2015-12-161-1/+1
| | | | | | successor llvm-svn: 255752
* Minor cleanup of Attribute code. NFC.George Burgess IV2015-12-162-48/+36
| | | | llvm-svn: 255751
* Fixed test case in rL255749: [SelectionDAGBuilder] Adds support for ↵Chen Li2015-12-161-1/+1
| | | | | | landingpads of token type. llvm-svn: 255750
* [SelectionDAGBuilder] Adds support for landingpads of token typeChen Li2015-12-163-0/+59
| | | | | | | | | | | | Summary: This patch adds a check in visitLandingPad to see if landingpad's result type is token type. If so, do not create DAG nodes for its exception pointer and selector value. This patch enables the back end to handle landingpads of token type. Reviewers: JosephTremoulet, majnemer, rnk Subscribers: sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15405 llvm-svn: 255749
* Fuzzer: Fix library dependencies.Peter Collingbourne2015-12-161-0/+6
| | | | | | | | Newer versions of libstdc++ (4.9+), as well as libc++, depend directly on libpthread from the standard library headers, so libfuzzer needs to declare a standard library dependency. llvm-svn: 255745
* Speculative fix for windows buildPhilip Reames2015-12-161-0/+1
| | | | llvm-svn: 255743
* [EarlyCSE] DSE of stores which write back loaded valuesPhilip Reames2015-12-162-0/+101
| | | | | | | | | | Extend EarlyCSE with an additional style of dead store elimination. If we write back a value just read from that memory location, we can eliminate the store under the assumption that the value hasn't changed. I'm implementing this mostly because I noticed the omission when looking at the code. It seemed strange to have InstCombine have a peephole which was more powerful than EarlyCSE. :) Differential Revision: http://reviews.llvm.org/D15397 llvm-svn: 255739
* [IR] Add support for floating pointer atomic loads and storesPhilip Reames2015-12-166-19/+314
| | | | | | | | | | | | | | | | This patch allows atomic loads and stores of floating point to be specified in the IR and adds an adapter to allow them to be lowered via existing backend support for bitcast-to-equivalent-integer idiom. Previously, the only way to specify a atomic float operation was to bitcast the pointer to a i32, load the value as an i32, then bitcast to a float. At it's most basic, this patch simply moves this expansion step to the point we start lowering to the backend. This patch does not add canonicalization rules to convert the bitcast idioms to the appropriate atomic loads. I plan to do that in the future, but for now, let's simply add the support. I'd like to get instruction selection working through at least one backend (x86-64) without the bitcast conversion before canonicalizing into this form. Similarly, I haven't yet added the target hooks to opt out of the lowering step I added to AtomicExpand. I figured it would more sense to add those once at least one backend (x86) was ready to actually opt out. As you can see from the included tests, the generated code quality is not great. I plan on submitting some patches to fix this, but help from others along that line would be very welcome. I'm not super familiar with the backend and my ramp up time may be material. Differential Revision: http://reviews.llvm.org/D15471 llvm-svn: 255737
* [sancov] blacklist support.Mike Aizatsky2015-12-169-15/+65
| | | | | | | | | | Summary: Using the blacklist the user can filter own unwanted functions from all outputs. By default blacklist contains "fun:__sancov*" line. Differential Revision: http://reviews.llvm.org/D15364 llvm-svn: 255732
* Fix typo in r255720Justin Bogner2015-12-161-1/+1
| | | | llvm-svn: 255724
* Test commit: fixed spelling error in comment.Wolfgang Pieb2015-12-161-1/+1
| | | | llvm-svn: 255721
* LPM: Simplify how passes mark loops for deletion. NFCJustin Bogner2015-12-164-45/+31
| | | | | | | | | | | | | | | | | | | | When a pass removes a loop it currently has to reach up into the LPPassManager's internals to update the state of the iteration over loops. This reverse dependency results in a pretty awkward interplay of the LPPassManager and its Passes. Here, we change this to instead keep track of when a loop has become "unlooped" in the Loop objects themselves, then the LPPassManager can check this and manipulate its own state directly. This opens the door to allow most of the loop passes to work without a backreference to the LPPassManager. I've kept passes calling the LPPassManager::deleteLoopFromQueue API now so I could put an assert in to prove that this is NFC, but a later pass will update passes just to preserve the LoopInfo directly and stop referencing the LPPassManager completely. llvm-svn: 255720
* Remove one of the void casts used to suppress unused variable warning.Richard Trieu2015-12-151-1/+0
| | | | llvm-svn: 255709
* Un-XFAIL JIT EH tests under [am]san.Peter Collingbourne2015-12-158-8/+8
| | | | | | | | | | These tests started passing after libcxxabi's r255559, which fixed a problem relating to how libcxxabi links its EH library. The test failures were caused by an issue with libc++, not the sanitizers (confirmed by building a pre-r255559 revision with libc++/libc++abi and without sanitizers), so they should never have been XFAILed under the sanitizers. llvm-svn: 255708
* [WinEH] Make llvm.x86.seh.recoverfp work on x64Reid Kleckner2015-12-1510-14/+41
| | | | | | | | | | | It adjusts from RSP-after-prologue to RBP, which is what SEH filters need to do before they can use llvm.localrecover. Fixes SEH filter captures, which were broken in r250088. Issue reported by Alex Crichton. llvm-svn: 255707
* Suppress unused variable warning in the no-asserts build.Evgeniy Stepanov2015-12-151-0/+1
| | | | llvm-svn: 255706
* Cast variable to void to resolve unused variable warning in non-asserts builds.Richard Trieu2015-12-151-0/+1
| | | | llvm-svn: 255704
* Fix "Not having LAHF/SAHF" assert.Hans Wennborg2015-12-151-1/+2
| | | | | | It wants to assert that the subtarget is 64-bit, not the register. llvm-svn: 255703
* AMDGPU/SI: Set the code object work group segment size when targeting HSATom Stellard2015-12-152-0/+6
| | | | | | | | | | Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D15493 llvm-svn: 255702
* [llvm-objdump/MachODump] Shrink code a little bit. NFC.Davide Italiano2015-12-151-4/+1
| | | | llvm-svn: 255701
* [x86] inline calls to fmaxf / llvm.maxnum.f32 using maxss (PR24475)Sanjay Patel2015-12-152-98/+228
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch improves on the suggested codegen from PR24475: https://llvm.org/bugs/show_bug.cgi?id=24475 but only for the fmaxf() case to start, so we can sort out any bugs before extending to fmin, f64, and vectors. The fmax / maxnum definitions provide us flexibility for signed zeros, so the only thing we have to worry about in this replacement sequence is NaN handling. Note 1: It may be better to implement this as lowerFMAXNUM(), but that exposes a problem: SelectionDAGBuilder::visitSelect() transforms compare/select instructions into FMAXNUM nodes if we declare FMAXNUM legal or custom. Perhaps that should be checking for NaN inputs or global unsafe-math before transforming? As it stands, that bypasses a big set of optimizations that the x86 backend already has in PerformSELECTCombine(). Note 2: The v2f32 test reveals another bug; the vector is extended to v4f32, so we have completely unnecessary operations happening on undef elements of the vector. Differential Revision: http://reviews.llvm.org/D15294 llvm-svn: 255700
* [Sparc] Tweak r255668: Use llvm_unreachable.James Y Knight2015-12-151-1/+1
| | | | llvm-svn: 255698
* Cross-DSO control flow integrity (LLVM part).Evgeniy Stepanov2015-12-157-0/+263
| | | | | | | | An LTO pass that generates a __cfi_check() function that validates a call based on a hash of the call-site-known type and the target pointer. llvm-svn: 255693
* AMDGPU/SI: Set the code objects private segment size when targeting HSA.Tom Stellard2015-12-153-1/+9
| | | | | | | | | | | | Summary: I'm not sure how things worked before without this. Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D15492 llvm-svn: 255692
* [LoopVectorizer] Refine loop vectorizer's register usage calculator by ↵Cong Hou2015-12-153-32/+178
| | | | | | | | | | | | | | | | | | | | | | ignoring specific instructions. (This is the third attempt to check in this patch, and the first two are r255454 and r255460. The once failed test file reg-usage.ll is now moved to test/Transform/LoopVectorize/X86 directory with target datalayout and target triple indicated.) LoopVectorizationCostModel::calculateRegisterUsage() is used to estimate the register usage for specific VFs. However, it takes into account many instructions that won't be vectorized, such as induction variables, GetElementPtr instruction, etc.. This makes the loop vectorizer too conservative when choosing VF. In this patch, the induction variables that won't be vectorized plus GetElementPtr instruction will be added to ValuesToIgnore set so that their register usage won't be considered any more. Differential revision: http://reviews.llvm.org/D15177 llvm-svn: 255691
* AMDGPU/SI: Emit constant variables in the .hsatext section when targeting HSATom Stellard2015-12-154-21/+15
| | | | | | | | | | Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D15426 llvm-svn: 255689
* Wrap include of <future> in some warning suppression pragmasReid Kleckner2015-12-151-1/+11
| | | | | | | | Eventually we may need to sink this include to the .cpp file or something to suport LLVM_ENABLE_THREADS=OFF, but this solves my immediate problem of fixing the build. llvm-svn: 255682
* [WebAssembly] Implement instruction selection for constant offsets in addresses.Dan Gohman2015-12-157-28/+574
| | | | | | | | | | | | | | | | | | | | Add instruction patterns for matching load and store instructions with constant offsets in addresses. The code is fairly redundant due to the need to replicate everything between imm, tglobaldadr, and texternalsym, but this appears to be common tablegen practice. The main alternative appears to be to introduce matching functions with C++ code, but sticking with purely generated matchers seems better for now. Also note that this doesn't yet support offsets from getelementptr, which will be the most common case; that will depend on a change in target-independent code in order to set the NoUnsignedWrap flag, which I'll submit separately. Until then, the testcase uses ptrtoint+add+inttoptr with a nuw on the add. Also implement isLegalAddressingMode with an approximation of this. Differential Revision: http://reviews.llvm.org/D15538 llvm-svn: 255681
* Initialize all bytes in vp data (msan error)Xinliang David Li2015-12-151-4/+5
| | | | llvm-svn: 255680
* Add support for the .debug_macro section of the forthcoming DWARF 5 spec.Eric Christopher2015-12-151-0/+20
| | | | | | Patch by B. Sivachandra Reddy! llvm-svn: 255679
* Fix clang-cl self-host with MSVC 2013 STL std::bind implementationReid Kleckner2015-12-151-1/+6
| | | | llvm-svn: 255678
* [WinEH] Remove unused intrinsic llvm.x86.seh.restoreframeReid Kleckner2015-12-154-74/+5
| | | | | | | We can clean this up now that we have the X86 CATCHRET instruction to restore the FP, SP, and BP. llvm-svn: 255677
* [WinEH] Use operand bundles to describe call sitesDavid Majnemer2015-12-1536-250/+303
| | | | | | | | | | | | | | | | | SimplifyCFG allows tail merging with code which terminates in unreachable which, in turn, makes it possible for an invoke to end up in a funclet which it was not originally part of. Using operand bundles on invokes allows us to determine whether or not an invoke was part of a funclet in the source program. Furthermore, it allows us to unambiguously answer questions about the legality of inlining into call sites which the personality may have trouble with. Differential Revision: http://reviews.llvm.org/D15517 llvm-svn: 255674
OpenPOWER on IntegriCloud