summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Have -Wuninitialized catch uninitalized use in overloaded operator arguments.Richard Trieu2014-10-313-4/+44
| | | | llvm-svn: 221000
* [analyzer] Helpful hints for Windows users of scan-build.Anton Yartsev2014-10-311-4/+27
| | | | llvm-svn: 220999
* R600: Add missing file to CMakeLists.txtTom Stellard2014-10-311-0/+1
| | | | llvm-svn: 220998
* R600: Don't promote allocas when one of the users is a ptrtoint instructionTom Stellard2014-10-312-6/+38
| | | | | | | | We need to figure out how to track ptrtoint values all the way until result is converted back to a pointer in order to correctly rewrite the pointer type. llvm-svn: 220997
* R600: Make sure to inline all internal functionsTom Stellard2014-10-315-1/+106
| | | | | | Function calls aren't supported yet. llvm-svn: 220996
* IR: Instruction::setMetadata() should use cast_or_nullDuncan P. N. Exon Smith2014-10-311-1/+1
| | | | | | | | | Not sure why this assertion didn't fire locally [1], but in r220994 `Instruction::setMetadata()` should be using `cast_or_null`. [1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/12327 llvm-svn: 220995
* IR: MDNode => Value: Instruction::setMetadata()Duncan P. N. Exon Smith2014-10-313-10/+13
| | | | | | | Change `Instruction::setMetadata()` API to accept `Value` instead of `MDNode`. Part of PR21433. llvm-svn: 220994
* MS ABI: Properly call global delete when invoking virtual destructorsDavid Majnemer2014-10-3112-149/+228
| | | | | | | | | | | | | | | | | | | | Summary: The Itanium ABI approach of using offset-to-top isn't possible with the MS ABI, it doesn't have that kind of information lying around. Instead, we do the following: - Call the virtual deleting destructor with the "don't delete the object flag" set. The virtual deleting destructor will return a pointer to 'this' adjusted to the most derived class. - Call the global delete using the adjusted 'this' pointer. Reviewers: rnk Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5996 llvm-svn: 220993
* C++-11 [qoi]. Do not warn on missing 'verride' on use ofFariborz Jahanian2014-10-313-0/+26
| | | | | | | macros in user code when macros themselves are defined in a system header. rdar://18295240 llvm-svn: 220992
* [asan] increase the initial buffer size in caller-callee dumperKostya Serebryany2014-10-311-1/+1
| | | | llvm-svn: 220991
* [PowerPC] Initial VSX intrinsic support, with min/max for vector doubleBill Schmidt2014-10-319-18/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have initial support for VSX, we can begin adding intrinsics for programmer access to VSX instructions. This patch performs the necessary enablement in the front end, and tests it by implementing intrinsics for minimum and maximum using the vector double data type. The main change in the front end is to no longer disallow "vector" and "double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector" and "long double" must still be disallowed. The new intrinsics are accessed via vec_max and vec_min with changes in lib/Headers/altivec.h. Note that for v4f32, we already access corresponding VMX builtins, but with VSX enabled we should use the forms that allow all 64 vector registers. The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def. I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is similar to, but much smaller than, builtins-ppc-altivec.c. This allows us to test VSX IR generation without duplicating CHECK lines for the existing bazillion Altivec tests. Since vector double is now legal when VSX is available, I've modified the error message, and changed where we test for it and for vector long double, since the target machine isn't visible in the old place. This serendipitously removed a not-pertinent warning about 'long' being deprecated when used with 'vector', when "vector long double" is encountered and we just want to issue an error. The existing tests test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been updated accordingly, and I've added test/Parser/vsx.c to verify that "vector double" is now legitimate with VSX enabled. There is a companion patch for LLVM. llvm-svn: 220989
* [PowerPC] Initial VSX intrinsic support, with min/max for vector doubleBill Schmidt2014-10-313-6/+167
| | | | | | | | | | | | | Now that we have initial support for VSX, we can begin adding intrinsics for programmer access to VSX instructions. This patch adds basic support for VSX intrinsics in general, and tests it by implementing intrinsics for minimum and maximum for the vector double data type. The LLVM portion of this is quite straightforward. There is a companion patch for Clang. llvm-svn: 220988
* [AArch64] Check Dest Register Liveness in CondOpt pass.Chad Rosier2014-10-311-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Our internal test reveals such case should not be transformed: cmp x17, #3 b.lt .LBB10_15 ... subs x12, x12, #1 b.gt .LBB10_1 where x12 is a liveout, becomes: cmp x17, #2 b.le .LBB10_15 ... subs x12, x12, #2 b.ge .LBB10_1 Unable to provide test case as it's difficult to reproduce on community branch. http://reviews.llvm.org/D6048 Patch by Zhaoshi Zheng <zhaoshiz@codeaurora.org>! llvm-svn: 220987
* ignore -mconstructor-aliases when adding field paddings for asanKostya Serebryany2014-10-312-0/+30
| | | | | | | | | | | | | | | | | | Summary: When we are adding field paddings for asan even an empty dtor has to remain in the code, so we ignore -mconstructor-aliases if the paddings are going to be added. Test Plan: added a test Reviewers: rsmith, rnk, rafael Reviewed By: rafael Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6038 llvm-svn: 220986
* [asan] do not treat inline asm calls as indirect callsKostya Serebryany2014-10-312-1/+4
| | | | llvm-svn: 220985
* clang-format: [Java] Improve line breaks around annotations.Daniel Jasper2014-10-314-6/+26
| | | | | | | | | | | | | | | | | Before: @SomeAnnotation("With some really looooooooooooooong text") private static final long something = 0L; void SomeFunction(@Nullable String something) {} After: @SomeAnnotation("With some really looooooooooooooong text") private static final long something = 0L; void SomeFunction(@Nullable String something) {} llvm-svn: 220984
* commit on behalf of Oleksiy Vyalov Fix junk content handling within ↵Shawn Best2014-10-311-55/+58
| | | | | | GDBRemoteCOmmunication::CheckForPacket 1. Avoid removing of an extra symbol from m_bytes. 2. iterate over m_bytes until useful content is found. Differential Revision: http://reviews.llvm.org/D6042 llvm-svn: 220983
* In ValueObjectDynamicValue, trust what comes fromSean Callanan2014-10-311-10/+1
| | | | | | | | | | | the runtime rather than trying to fix it up, because now those types have ivars regardless of whether they come from "frame variable" or from expressions. Patch by Enrico Granata. llvm-svn: 220982
* Updated the Objective-C runtime type vendor toSean Callanan2014-10-311-5/+41
| | | | | | | load ivars into classes that are reported to the Objective-C runtime. llvm-svn: 220981
* - Fixed a bug where ::Describe for class descriptorsSean Callanan2014-10-311-16/+19
| | | | | | | | | | would fail if the class had no ivars. - Updated use of the RealizeType API by the class descriptors to use "for_expression" rather than the misnamed "allow_unknownanytype." llvm-svn: 220980
* - Use "for_expression" rather than "allow_unknownanytype"Sean Callanan2014-10-314-40/+71
| | | | | | | | | | | | | to indicate that we're doing stuff for the expression parser. - When for_expression is true, look through @s and find the actual class rather than just returning id. - Rename BuildObjCObjectType to BuildObjCObjectPointerType since it's actually returning an object *pointer* type. llvm-svn: 220979
* [CodeGenPrepare] Move extractelement close to store if they can be combined.Quentin Colombet2014-10-315-2/+823
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds an optimization in CodeGenPrepare to move an extractelement right before a store when the target can combine them. The optimization may promote any scalar operations to vector operations in the way to make that possible. ** Context ** Some targets use different register files for both vector and scalar operations. This means that transitioning from one domain to another may incur copy from one register file to another. These copies are not coalescable and may be expensive. For example, according to the scheduling model, on cortex-A8 a vector to GPR move is 20 cycles. ** Motivating Example ** Let us consider an example: define void @foo(<2 x i32>* %addr1, i32* %dest) { %in1 = load <2 x i32>* %addr1, align 8 %extract = extractelement <2 x i32> %in1, i32 1 %out = or i32 %extract, 1 store i32 %out, i32* %dest, align 4 ret void } As it is, this IR generates the following assembly on armv7: vldr d16, [r0] @vector load vmov.32 r0, d16[1] @ cross-register-file copy: 20 cycles orr r0, r0, #1 @ scalar bitwise or str r0, [r1] @ scalar store bx lr Whereas we could generate much faster code: vldr d16, [r0] @ vector load vorr.i32 d16, #0x1 @ vector bitwise or vst1.32 {d16[1]}, [r1:32] @ vector extract + store bx lr Half of the computation made in the vector is useless, but this allows to get rid of the expensive cross-register-file copy. ** Proposed Solution ** To avoid this cross-register-copy penalty, we promote the scalar operations to vector operations. The penalty will be removed if we manage to promote the whole chain of computation in the vector domain. Currently, we do that only when the chain of computation ends by a store and the target is able to combine an extract with a store. Stores are the most likely candidates, because other instructions produce values that would need to be promoted and so, extracted as some point[1]. Moreover, this is customary that targets feature stores that perform a vector extract (see AArch64 and X86 for instance). The proposed implementation relies on the TargetTransformInfo to decide whether or not it is beneficial to promote a chain of computation in the vector domain. Unfortunately, this interface is rather inaccurate for this level of details and although this optimization may be beneficial for X86 and AArch64, the inaccuracy will lead to the optimization being too aggressive. Basically in TargetTransformInfo, everything that is legal has a cost of 1, whereas, even if a vector type is legal, usually a vector operation is slightly more expensive than its scalar counterpart. That will lead to too many promotions that may not be counter balanced by the saving of the cross-register-file copy. For instance, on AArch64 this penalty is just 4 cycles. For now, the optimization is just enabled for ARM prior than v8, since those processors have a larger penalty on cross-register-file copies, and the scope is limited to basic blocks. Because of these two factors, we limit the effects of the inaccuracy. Indeed, I did not want to build up a fancy cost model with block frequency and everything on top of that. [1] We can imagine targets that can combine an extractelement with other instructions than just stores. If we want to go into that direction, the current interfaces must be augmented and, moreover, I think this becomes a global isel problem. Differential Revision: http://reviews.llvm.org/D5921 <rdar://problem/14170854> llvm-svn: 220978
* clang-format: [js] Updates to Google's JavaScript style.Daniel Jasper2014-10-314-21/+19
| | | | | | The style guide is changing.. llvm-svn: 220977
* [analyzer] Rename NewDeleteLeaks checker in the test script.Anna Zaks2014-10-311-1/+1
| | | | | | Fixup to r220289. llvm-svn: 220976
* [asan] run-time part of the caller-callee coverage instrumentationKostya Serebryany2014-10-312-0/+168
| | | | llvm-svn: 220975
* Fix the buildDavid Blaikie2014-10-311-1/+1
| | | | llvm-svn: 220974
* [asan] fix caller-calee instrumentation to emit new cache for every call siteKostya Serebryany2014-10-312-5/+9
| | | | llvm-svn: 220973
* Fix ARM HVA classification of classes with non-virtual basesReid Kleckner2014-10-316-188/+261
| | | | | | | | | | | | | | | | Reuse the PPC64 HVA detection algorithm for ARM and AArch64. This is a nice code deduplication, since they are roughly identical. A few virtual method extension points are needed to understand how big an HVA can be and what element types it can have for a given architecture. Also make the record expansion code work in the presence of non-virtual bases. Reviewed By: uweigand, asl Differential Revision: http://reviews.llvm.org/D6045 llvm-svn: 220972
* Remove the wrongly named and now empty Ocaml directoryJustin Bogner2014-10-310-0/+0
| | | | llvm-svn: 220971
* Fix unused-function warning differently from r220853David Blaikie2014-10-311-8/+1
| | | | | | | | | | Rather than executing this code only needed for an assertion even in a non-asserts build, just roll the function into the assert. The assertion text literally describes the two cases so it doesn't seem like this benefits much from having a separate function (& have to hassle about ifndef NDEBUG it out, etc) llvm-svn: 220970
* Update the non-pthreads fallback for RWMutex on UnixDavid Blaikie2014-10-311-6/+6
| | | | | | | | | | Tested this by #if 0'ing out the pthreads implementation, which indicated that this fallback was not currently compiling successfully and applying this patch resolves that. Patch by Andy Chien. llvm-svn: 220969
* Unify and update link-messages.ll and redefinition.ll. NFC.Rafael Espindola2014-10-313-17/+5
| | | | llvm-svn: 220968
* Correct assert text from r220923David Blaikie2014-10-311-1/+1
| | | | | | Noticed in post-commit review by Adrian Prantl. llvm-svn: 220967
* [libclang] Disable spell-checking and warnings during code-completion since ↵Argyrios Kyrtzidis2014-10-311-0/+4
| | | | | | they are not needed. llvm-svn: 220966
* [Makefile] If ENABLE_CLANG_ARCMT=0 it seems we don't build libclang, so the ↵Argyrios Kyrtzidis2014-10-311-2/+2
| | | | | | | | unittests for libclang should be disabled too. This is a modified patch provided by Vassil Vassilev. llvm-svn: 220965
* Mark a few variables const. NFC.Rafael Espindola2014-10-311-9/+11
| | | | llvm-svn: 220964
* Fix some bugs from D5988Justin Hibbits2014-10-319-10/+61
| | | | | | | | | | | | | | | | | | Summary: Ed Maste found some problems with the commit in D5988. Address most of these. While here, also add floating point return handling. This doesn't handle 128-bit long double yet. Since I don't have any system that uses it, I don't currently have plans to implement it. Reviewers: emaste Reviewed By: emaste Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D6049 llvm-svn: 220963
* [CMake] llvm/examples: Update libdeps for unoptimized builds.NAKAMURA Takumi2014-10-312-0/+2
| | | | llvm-svn: 220962
* [AArch64] CondOpt pass is missing FCMP instructions when searching backward forChad Rosier2014-10-312-0/+75
| | | | | | | | | a CMP which defines the flags used by B.CC. http://reviews.llvm.org/D6047 Patch by Zhaoshi Zheng <zhaoshiz@codeaurora.org>! llvm-svn: 220961
* [SCEV] Improve Scalar Evolution's use of no {un,}signed wrap flagsBradley Smith2014-10-313-8/+79
| | | | | | | | | | | | | | | In a case where we have a no {un,}signed wrap flag on the increment, if RHS - Start is constant then we can avoid inserting a max operation bewteen the two, since we can statically determine which is greater. This allows us to unroll loops such as: void testcase3(int v) { for (int i=v; i<=v+1; ++i) f(i); } llvm-svn: 220960
* [PowerPC] Load BlockAddress values from the TOC in 64-bit SVR4 codeUlrich Weigand2014-10-315-10/+63
| | | | | | | | | | | | | | Since block address values can be larger than 2GB in 64-bit code, they cannot be loaded simply using an @l / @ha pair, but instead must be loaded from the TOC, just like GlobalAddress, ConstantPool, and JumpTable values are. The commit also fixes a bug in PPCLinuxAsmPrinter::doFinalization where temporary labels could not be used as TOC values, since code would attempt (and fail) to use GetOrCreateSymbol to create a symbol of the same name as the temporary label. llvm-svn: 220959
* [OCaml] Ensure consistent naming.Peter Zotov2014-10-3120-3/+3
| | | | | | | | | Specifically: * Directories match module names. * Test names match module names. * The language is called "OCaml", not "Ocaml". llvm-svn: 220958
* [OCaml] Rework Llvm_executionengine using ctypes.Peter Zotov2014-10-317-602/+190
| | | | | | | | | | | | | | | | | | | | | | | | Since JIT->MCJIT migration, most of the ExecutionEngine interface became deprecated and/or broken. This especially affected the OCaml bindings, as runFunction is no longer available, and unlike in C, it is not possible to coerce a pointer to a function and call it in OCaml. In practice, LLVM 3.5 shipped completely unusable Llvm_executionengine. The GenericValue interface and runFunction were essentially a poor man's FFI. As such, this interface was removed and instead a dependency on ctypes >=0.3 added, which handled platform-specific aspects of accessing data and calling functions. The new interface does not expose JIT (which is a shim around MCJIT), as well as the interpreter (which can't handle a lot of valid IR). Llvm_executionengine.add_global_mapping is currently unusable due to PR20656. llvm-svn: 220957
* Remove StorageClass typedefs from VarDecl and FunctionDecl since ↵Craig Topper2014-10-313-19/+12
| | | | | | StorageClass is in the clang namespace. llvm-svn: 220956
* Remove CastKind typedef from CastExpr since CastKind is in the clang namespace.Craig Topper2014-10-313-6/+3
| | | | llvm-svn: 220955
* Remove a couple typedefs for things in the clang namespace with the same ↵Craig Topper2014-10-313-13/+6
| | | | | | name. Remove a typedef that matches an identical one in the clang namespace. llvm-svn: 220954
* Move an input file to Inputs instead of using RUN: true.Rafael Espindola2014-10-312-7/+3
| | | | llvm-svn: 220953
* Object, COFF: Cleanup symbol type code, improve binutils compatibilityDavid Majnemer2014-10-319-68/+112
| | | | | | | Do a better job classifying symbols. This increases the consistency between the COFF handling code and the ELF side of things. llvm-svn: 220952
* merge tests for constant linking.Rafael Espindola2014-10-316-27/+10
| | | | llvm-svn: 220951
* Move definition closer to use. NFC.Rafael Espindola2014-10-311-3/+3
| | | | llvm-svn: 220949
OpenPOWER on IntegriCloud