summaryrefslogtreecommitdiffstats
path: root/llvm/test
Commit message (Collapse)AuthorAgeFilesLines
* Add the code and test cases for 32-bit Intel to llvm-objdump’s Mach-O ↵Kevin Enderby2014-11-044-0/+17
| | | | | | symbolizer. llvm-svn: 221211
* [Hexagon] Reverting 220584 to address ASAN errors.Colin LeMahieu2014-11-042-7/+0
| | | | llvm-svn: 221210
* Use AA in LoadCombineHal Finkel2014-11-032-0/+83
| | | | | | | | | | | | | | LoadCombine can be smarter about aborting when a writing instruction is encountered, instead of aborting upon encountering any writing instruction, use an AliasSetTracker, and only abort when encountering some write that might alias with the loads that could potentially be combined. This was originally motivated by comments made (and a test case provided) by David Majnemer in response to PR21448. It turned out that LoadCombine was not responsible for that PR, but LoadCombine should also be improved so that unrelated stores (and @llvm.assume) don't interrupt load combining. llvm-svn: 221203
* Handle ASAN_OPTIONS and UBSAN_OPTIONS in TestingConfig.pyRafael Espindola2014-11-031-5/+0
| | | | | | | | Currently they are passed to tests of llvm itself, but not, for example, lld. With this patch the options are visible in every test. llvm-svn: 221198
* InstCombine: Remove infinite loop caused by FoldOpIntoPhiDavid Majnemer2014-11-032-16/+23
| | | | | | | | | | | | | | FoldOpIntoPhi could create an infinite loop if the PHI could potentially reach a BB it was considering inserting instructions into. The instructions it would insert would eventually lead to other combines firing which would, again, lead to FoldOpIntoPhi firing. The solution is to handicap FoldOpIntoPhi so that it doesn't attempt to insert instructions that the PHI might reach. This fixes PR21377. llvm-svn: 221187
* [ARM, inline-asm] Fix ARMTargetLowering::getRegForInlineAsmConstraint to returnAkira Hatanaka2014-11-031-1/+12
| | | | | | | | | | | | register class tGPRRegClass if the target is thumb1. This commit fixes a crash that occurs during register allocation which was triggered when a virtual register defined by an inline-asm instruction had to be spilled. rdar://problem/18740489 llvm-svn: 221178
* [X86] 8bit divrem: Improve codegen for AH register extraction.Ahmed Bougacha2014-11-031-0/+100
| | | | | | | | | | | | | | | | | | | | | | | | For 8-bit divrems where the remainder is used, we used to generate: divb %sil shrw $8, %ax movzbl %al, %eax That was to avoid an H-reg access, which is problematic mainly because it isn't possible in REX-prefixed instructions. This patch optimizes that to: divb %sil movzbl %ah, %eax To do that, we explicitly extend AH, and extract the L-subreg in the resulting register. The extension is done using the NOREX variants of MOVZX. To support signed operations, MOVSX_NOREX is also added. Further, this introduces a new SDNode type, [us]divrem_ext_hreg, which is then lowered to a sequence containing a single zext (rather than 2). Differential Revision: http://reviews.llvm.org/D6064 llvm-svn: 221176
* EarlyCSE should ignore calls to @llvm.assumeHal Finkel2014-11-031-0/+36
| | | | | | | | | | | | EarlyCSE uses a simple generation scheme for handling memory-based dependencies, and calls to @llvm.assume (which are marked as writing to memory to ensure the preservation of control dependencies) disturb that scheme unnecessarily. Skipping calls to @llvm.assume is legal, and the alternative (adding AA calls in EarlyCSE) is likely undesirable (we have GVN for that). Fixes PR21448. llvm-svn: 221175
* Reapply: R600: Make sure to inline all internal functionsTom Stellard2014-11-032-1/+25
| | | | | | | | Function calls aren't supported yet. This was reverted due to build breakages, which should be fixed now. llvm-svn: 221173
* [Reassociate] Canonicalize negative constants out of expressions.Chad Rosier2014-11-033-70/+236
| | | | | | | | | This gives CSE/GVN more options to eliminate duplicate expressions. This is a follow up patch to http://reviews.llvm.org/D4904. http://reviews.llvm.org/D5363 llvm-svn: 221171
* Normally an 'optnone' function goes through fast-isel, which does notPaul Robinson2014-11-032-0/+170
| | | | | | | | | | | | call DAGCombiner. But we ran into a case (on Windows) where the calling convention causes argument lowering to bail out of fast-isel, and we end up in CodeGenAndEmitDAG() which does run DAGCombiner. So, we need to make DAGCombiner check for 'optnone' after all. Commit includes the test that found this, plus another one that got missed in the original optnone work. llvm-svn: 221168
* Remove the cortex-a9-mp CPU.Charlie Turner2014-11-035-24/+6
| | | | | | | | | | | | | | | | | | This CPU definition is redundant. The Cortex-A9 is defined as supporting multiprocessing extensions. Remove its definition and update appropriate tests. LLVM defines both a cortex-a9 CPU and a cortex-a9-mp CPU. The only difference between the two CPU definitions in ARM.td is that cortex-a9-mp contains the feature FeatureMP for multiprocessing extensions. This is redundant since the Cortex-A9 is defined as having multiprocessing extensions in the TRMs. armcc also defines the Cortex-A9 as having multiprocessing extensions by default. Change-Id: Ifcadaa6c322be0a33d9d2a39cfdd7da1d75981a7 llvm-svn: 221166
* [AArch64] Fix miscompile of comparison with 0xffffffffffffffffOliver Stannard2014-11-031-0/+36
| | | | | | | Some literals in the AArch64 backend had 15 'f's rather than 16, causing comparisons with a constant 0xffffffffffffffff to be miscompiled. llvm-svn: 221157
* Handle ctor/init_array initialization.Sid Manning2014-11-031-0/+14
| | | | | | | | | Hexagon was not calling InitializeELF and could not select between ctors and init_array. Phabricator revision: http://reviews.llvm.org/D6061 llvm-svn: 221156
* Merge the directive-eabi_attribute.s and directive-eabi_attribute-2.s tests.Charlie Turner2014-11-032-142/+146
| | | | | | | | | | | | | test/MC/ARM/directive-eabi_attribute.s had gotten out-of-sync with test/MC/ARM/directive-eabi_attribute-2.s. The former tests the encoding of build attributes in object files, and the latter the encoding in assembly files. Since both these tests need to be updated at the same time, it makes sense to combine them into a single test. The object file encodings are being checked against the ouput of -arm-attributes rather than by direct byte comparisons which makes for easier reading. Change-Id: I0075de506ae5626fb2fa235383fe5ce6a65a15a9 llvm-svn: 221155
* Add CRLF support to LineIterator.Rafael Espindola2014-11-032-0/+3
| | | | | | | The MRI scripts have to work with CRLF, and in general it is probably a good idea to support this in a core utility like LineIterator. llvm-svn: 221153
* Revert r221150, as it broke sanitizer testsOliver Stannard2014-11-032-21/+2
| | | | llvm-svn: 221151
* Emit .eh_frame with relocations to functions, rather than sectionsOliver Stannard2014-11-032-2/+21
| | | | | | | | | | | | | | | | | | | | | | | When LLVM emits DWARF call frame information, it currently creates a local, section-relative symbol in the code section, which is pointed to by a relocation on the .eh_frame section. However, for C++ we emit some functions in section groups, and the SysV ABI has some rules to make it easier to remove these sections (http://www.sco.com/developers/gabi/latest/ch4.sheader.html#section_group_rules): A symbol table entry with STB_LOCAL binding that is defined relative to one of a group's sections, and that is contained in a symbol table section that is not part of the group, must be discarded if the group members are discarded. References to this symbol table entry from outside the group are not allowed. This means that we need to use the function symbol for the relocation, not a temporary symbol. There was a comment in the code claiming that the local symbol was used to avoid creating a relocation, but a relocation must be created anyway as the code and CFI are in different sections. llvm-svn: 221150
* Unbreak build.Peter Zotov2014-11-031-1/+1
| | | | | | A bug in lit.cfg was introduced in r221137. llvm-svn: 221144
* [OCaml] Avoid embedding absolute paths into executables.Peter Zotov2014-11-031-1/+2
| | | | | | | | | | | | Bindings built out-of-tree, e.g. via OPAM, should append a line to META.llvm like the following: linkopts = "-cclib -L$libdir -cclib -Wl,-rpath,$libdir" where $libdir is the lib/ directory where LLVM libraries are installed. llvm-svn: 221139
* [OCaml] Run tests twice, with ocamlc and ocamlopt (if available)Peter Zotov2014-11-0314-25/+60
| | | | | | | | | | ocamlc and ocamlopt expose a distinct set of buildsystem bugs, e.g. only ocamlc would detect -custom or -dllib-related bugs, and as all buildbots will have ocamlopt, these bugs will stay hidden. This change should add no more than 30 seconds of testing time. llvm-svn: 221137
* Forgot to add input file for test added in r221133David Majnemer2014-11-031-0/+0
| | | | llvm-svn: 221134
* llvm-vtabledump: Handle Itanium VTablesDavid Majnemer2014-11-031-48/+56
| | | | | | Add support in the vtable dumper for the Itanium ABI. llvm-svn: 221133
* InstCombine: Combine (X | Y) - X to (~X & Y)David Majnemer2014-11-031-0/+10
| | | | | | | | This implements the transformation from (X | Y) - X to (~X & Y). Differential Revision: http://reviews.llvm.org/D5791 llvm-svn: 221129
* Revert r221096 bringing back r221014 with a fix.Rafael Espindola2014-11-022-3/+11
| | | | | | | | | | | | | | | | | The issue was that linkAppendingVarProto does the full linking job, including deleting the old dst variable. The fix is just to call it and return early if we have a GV with appending linkage. original message: Refactor duplicated code in liking GlobalValues. There is quiet a bit of logic that is common to any GlobalValue but was duplicated for Functions, GlobalVariables and GlobalAliases. While at it, merge visibility even when comdats are used, fixing pr21415. llvm-svn: 221098
* Revert r221014: "Refactor duplicated code in liking GlobalValues."Chandler Carruth2014-11-022-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit introduces heap-use-after-free detected by ASan. Here is the output for one of several tests that detect it: ******************** TEST 'LLVM :: Linker/AppendingLinkage.ll' FAILED ******************** Command Output (stderr): -- ================================================================= ==2122==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c00000b9c8 at pc 0x0000005d05d1 bp 0x7fff64ed27c0 sp 0x7fff64ed27b8 READ of size 4 at 0x60c00000b9c8 thread T0 #0 0x5d05d0 in llvm::GlobalValue::setUnnamedAddr(bool) /usr/local/google/home/chandlerc/src/llvm/build/../include/llvm/IR/GlobalValue.h:115:35 #1 0x69fff1 in (anonymous namespace)::ModuleLinker::linkGlobalValueProto(llvm::GlobalValue*) /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkModules.cpp:1041:5 #2 0x697229 in (anonymous namespace)::ModuleLinker::run() /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkModules.cpp:1485:9 #3 0x696542 in llvm::Linker::linkInModule(llvm::Module*) /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkModules.cpp:1621:10 #4 0x4a2db7 in main /usr/local/google/home/chandlerc/src/llvm/build/../tools/llvm-link/llvm-link.cpp:116:9 #5 0x7f4ae61e5ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287 #6 0x41eb71 in _start (/usr/local/google/home/chandlerc/src/llvm/build/bin/llvm-link+0x41eb71) 0x60c00000b9c8 is located 72 bytes inside of 128-byte region [0x60c00000b980,0x60c00000ba00) freed by thread T0 here: #0 0x4a1e6b in operator delete(void*) /usr/local/google/home/chandlerc/src/llvm/opt-build/../projects/compiler-rt/lib/asan/asan_new_delete.cc:94:3 #1 0x5d1a7a in llvm::iplist<llvm::GlobalVariable, llvm::ilist_traits<llvm::GlobalVariable> >::erase(llvm::ilist_iterator<llvm::GlobalVariable>) /usr/local/google/home/chandlerc/src/llvm/build/../inclu de/llvm/ADT/ilist.h:466:5 #2 0x5d1980 in llvm::GlobalVariable::eraseFromParent() /usr/local/google/home/chandlerc/src/llvm/build/../lib/IR/Globals.cpp:204:3 #3 0x6a8a4d in (anonymous namespace)::ModuleLinker::linkAppendingVarProto(llvm::GlobalVariable*, llvm::GlobalVariable const*) /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkModules. cpp:980:3 #4 0x6a7403 in (anonymous namespace)::ModuleLinker::linkGlobalVariableProto(llvm::GlobalVariable const*, llvm::GlobalValue*, bool) /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkMod ules.cpp:1074:11 #5 0x69ff4e in (anonymous namespace)::ModuleLinker::linkGlobalValueProto(llvm::GlobalValue*) /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkModules.cpp:1028:13 #6 0x697229 in (anonymous namespace)::ModuleLinker::run() /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkModules.cpp:1485:9 #7 0x696542 in llvm::Linker::linkInModule(llvm::Module*) /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkModules.cpp:1621:10 #8 0x4a2db7 in main /usr/local/google/home/chandlerc/src/llvm/build/../tools/llvm-link/llvm-link.cpp:116:9 #9 0x7f4ae61e5ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287 previously allocated by thread T0 here: #0 0x4a192b in operator new(unsigned long) /usr/local/google/home/chandlerc/src/llvm/opt-build/../projects/compiler-rt/lib/asan/asan_new_delete.cc:62:35 #1 0x61d85c in llvm::User::operator new(unsigned long, unsigned int) /usr/local/google/home/chandlerc/src/llvm/build/../lib/IR/User.cpp:57:19 #2 0x6a7525 in (anonymous namespace)::ModuleLinker::linkGlobalVariableProto(llvm::GlobalVariable const*, llvm::GlobalValue*, bool) /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkMod ules.cpp:1100:3 #3 0x69ff4e in (anonymous namespace)::ModuleLinker::linkGlobalValueProto(llvm::GlobalValue*) /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkModules.cpp:1028:13 #4 0x697229 in (anonymous namespace)::ModuleLinker::run() /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkModules.cpp:1485:9 #5 0x696542 in llvm::Linker::linkInModule(llvm::Module*) /usr/local/google/home/chandlerc/src/llvm/build/../lib/Linker/LinkModules.cpp:1621:10 #6 0x4a2db7 in main /usr/local/google/home/chandlerc/src/llvm/build/../tools/llvm-link/llvm-link.cpp:116:9 #7 0x7f4ae61e5ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287 SUMMARY: AddressSanitizer: heap-use-after-free /usr/local/google/home/chandlerc/src/llvm/build/../include/llvm/IR/GlobalValue.h:115 llvm::GlobalValue::setUnnamedAddr(bool) Shadow bytes around the buggy address: 0x0c187fff96e0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c187fff96f0: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa 0x0c187fff9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa 0x0c187fff9710: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c187fff9720: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa =>0x0c187fff9730: fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd 0x0c187fff9740: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c187fff9750: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa 0x0c187fff9760: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c187fff9770: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c187fff9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac ASan internal: fe ==2122==ABORTING llvm-svn: 221096
* Use Alias Analysis to hoist 2 loads from diamond to the common predecessor ↵Elena Demikhovsky2014-11-021-0/+64
| | | | | | | | | | basic block. Alias Analysis allows to detect real barriers for load hoisting. Review in http://reviews.llvm.org/D5991 llvm-svn: 221091
* Update test to use llvm-readobj. NFC.Rafael Espindola2014-11-021-29/+9
| | | | llvm-svn: 221074
* Test 221067 in a fixed-target test so as not to fail on targets with ↵David Blaikie2014-11-011-0/+1
| | | | | | different DWARF encodings llvm-svn: 221071
* InstCombine: Don't assume that m_ZExt matches an InstructionDavid Majnemer2014-11-011-0/+13
| | | | | | | | | | | | m_ZExt might bind against a ConstantExpr instead of an Instruction. Assuming this, using cast<Instruction>, results in InstCombine crashing. Instead, introduce ZExtOperator to bridge both Instruction and ConstantExpr ZExts. This fixes PR21445. llvm-svn: 221069
* Remove test coverage added in 221067 due to it being non-portable.David Blaikie2014-11-011-1/+1
| | | | | | | Will try to find a portable way to test this (or a fixed-target test I can add such coverage to) shortly. llvm-svn: 221068
* Remove DwarfUnit::LabelEnd in favor of computing the length of the section ↵David Blaikie2014-11-012-3/+3
| | | | | | | | | | directly This was a compile-unit specific label (unused in type units) and seems unnecessary anyway when we can more easily directly compute the size of the compile unit. llvm-svn: 221067
* InstCombine: Combine (X+cst) < 0 --> X < -cstDavid Majnemer2014-11-011-0/+32
| | | | | | | | | | | | | This can happen pretty often in code that looks like: int foo = bar - 1; if (foo < 0) do stuff In this case, bar < 1 is an equivalent condition. This transform requires that the add instruction be annotated with nsw. llvm-svn: 221045
* Revert "Temporarily revert r220777 to sort out build bot breakage."Adrian Prantl2014-11-012-2/+46
| | | | | | | This reverts commit r221028. Later commits depend on this and reverting just this one causes even more bots to fail. llvm-svn: 221041
* Add show and merge tools for sample PGO profiles.Diego Novillo2014-11-012-0/+42
| | | | | | | | | | | | | | | | | | | | | Summary: This patch extends the 'show' and 'merge' commands in llvm-profdata to handle sample PGO formats. Using the 'merge' command it is now possible to convert one sample PGO format to another. The only format that is currently not working is 'gcc'. I still need to implement support for it in lib/ProfileData. The changes in the sample profile support classes are needed for the merge operation. Reviewers: bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6065 llvm-svn: 221032
* Temporarily revert r220777 to sort out build bot breakage.Adrian Prantl2014-11-012-46/+2
| | | | | | "[x86] Simplify vector selection if condition value type matches vselect value type and true value is all ones or false value is all zeros." llvm-svn: 221028
* Revert "R600: Make sure to inline all internal functions"Reid Kleckner2014-10-312-25/+1
| | | | | | | | | This reverts commit r220996. It introduced layering violations causing link errors in many configurations. llvm-svn: 221020
* Refactor duplicated code in liking GlobalValues.Rafael Espindola2014-10-312-3/+11
| | | | | | | | | There is quiet a bit of logic that is common to any GlobalValue but was duplicated for Functions, GlobalVariables and GlobalAliases. While at it, merge visibility even when comdats are used, fixing pr21415. llvm-svn: 221014
* Correctly update dom-tree after loop vectorizer.Michael Zolotukhin2014-10-311-0/+142
| | | | llvm-svn: 221009
* R600: Don't promote allocas when one of the users is a ptrtoint instructionTom Stellard2014-10-311-0/+19
| | | | | | | | 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-312-1/+25
| | | | | | Function calls aren't supported yet. llvm-svn: 220996
* [PowerPC] Initial VSX intrinsic support, with min/max for vector doubleBill Schmidt2014-10-311-0/+98
| | | | | | | | | | | | | 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
* [asan] do not treat inline asm calls as indirect callsKostya Serebryany2014-10-311-0/+1
| | | | llvm-svn: 220985
* [CodeGenPrepare] Move extractelement close to store if they can be combined.Quentin Colombet2014-10-311-0/+403
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [asan] fix caller-calee instrumentation to emit new cache for every call siteKostya Serebryany2014-10-311-1/+5
| | | | llvm-svn: 220973
* Unify and update link-messages.ll and redefinition.ll. NFC.Rafael Espindola2014-10-313-17/+5
| | | | llvm-svn: 220968
* [AArch64] CondOpt pass is missing FCMP instructions when searching backward forChad Rosier2014-10-311-0/+64
| | | | | | | | | 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-312-2/+53
| | | | | | | | | | | | | | | 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-311-0/+26
| | | | | | | | | | | | | | 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-3114-0/+0
| | | | | | | | | Specifically: * Directories match module names. * Test names match module names. * The language is called "OCaml", not "Ocaml". llvm-svn: 220958
OpenPOWER on IntegriCloud