summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [Orc] Rename IndirectStubsManagerBase method 'init' to 'createStubs'.Lang Hames2015-10-293-4/+4
| | | | llvm-svn: 251641
* [FunctionAttrs] Provide a single SCC node set to all of theChandler Carruth2015-10-291-91/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | transformations in FunctionAttrs rather than building a new one each time. This isn't trivial because there are different heuristics from different passes for exactly what set they want. The primary difference is whether an *overridable* function completely disables the synthesis of attributes. I've modeled this by directly testing for overridable, and using the common set that excludes external and opt-none functions. This does cause some changes by disabling more optimizations in the face of opt-none. Specifically, we were still optimizing *calls* to opt-none functions based on their attributes, just not the bodies. It seems better to be conservative on both fronts given the intended semanticas here (best effort to not assume or disturb anything). I've not tried to test this change as it seems complex, brittle, and not important to the implicit contract of opt-none. Instead, it seems more like a choice that should be dictated by the simplified implementation and the change to be acceptable differences within the space of opt-none. A big benefit here is that these transformations no longer rely on the legacy pass manager's SCC types, they just work on generic sets of function pointers. This will make it easy to re-use their logic in the new pass manager. I've also made the transforms static functions instead of members where trivial while I was touching the signatures. llvm-svn: 251640
* add support of the latest Ubuntu (Xenial Xerus)Sylvestre Ledru2015-10-291-1/+3
| | | | llvm-svn: 251639
* Add a link to the DXR projectEhsan Akhgari2015-10-291-0/+11
| | | | | | | | DXR is a project developed at Mozilla that implements a code indexing and browsing utility on top of libclang that has features such as call graph querying. llvm-svn: 251638
* [lld][MachO] Make sure LC_RPATH command size is a multiple of the pointer size.Lang Hames2015-10-292-3/+3
| | | | llvm-svn: 251637
* Better handle the arguments common to all MI commands.Hafiz Abid Qadeer2015-10-2920-142/+67
| | | | | | | | | | | | | | | | | | | | | | | | Summary: I observed that eclipse was passing --thread-group for many other commands then we are currently handling. Looking at the MI documentation, the following link states that each MI command accept the --thread and --frame option. Looking at the GDB implementation, it seems that apart from these 2, --thread-group is also handled the same way. https://sourceware.org/gdb/onlinedocs/gdb/Context-management.html#Context-management So instead of handling those arguments in every comamnds, I have moved them into the base class and removed them from elsewhere. Now any command can use these arguments. The patch seems big but most of the changes are mechanical. Reviewers: ki.stfu Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14177 llvm-svn: 251636
* Revert r251593.Diego Novillo2015-10-291-1/+1
| | | | | | | The patch in r251593 was only papering over the problem. The actual fix was committed in r251623. llvm-svn: 251635
* [SystemZ] Make the CCRegs regclass non-allocatable.Jonas Paulsson2015-10-295-5/+41
| | | | | | | | | | | | | | | | | | | | | This was discovered to be necessary while running memchr-01.ll with -verify-machinstrs, because it is not allowed to have a phys reg live accross block boundaries while on SSA form, if the register is allocatable (expect in entry block and landing pads). In this test case, stringRRE pseudos are expanded after isel by adding a loop block which produces a live out CC register. To make the test pass, it was also necessary to not say that StringRRELoop pseudo uses R0L, this is only true for the StringRRE opcode. -verify-machineinstrs added to memchr-01.ll test. New test case int-cmp-51.ll to test that MachineCSE can eliminate an identical compare (which it couldn't do before). Reviewed by Ulrich Weigand llvm-svn: 251634
* [mips] Add support for the new mips-mti-linux toolchain.Vasileios Kalintiris2015-10-2917-27/+298
| | | | | | | | | | The original commit in r249137 added the mips-mti-linux toolchain. However, the newly added tests of that commit failed in few buildbots. This commit re-applies the original changes but XFAILs the test file which caused the buildbot failures. This will allow us to examine what's going wrong without having to commit/revert large changes. llvm-svn: 251633
* AMDGPU/SI: handle undef for llvm.SI.packf16Marek Olsak2015-10-292-0/+33
| | | | llvm-svn: 251632
* AMDGPU/SI: use S_OR for fneg (fabs f32)Marek Olsak2015-10-292-20/+10
| | | | llvm-svn: 251631
* AMDGPU/SI: use S_AND for i1 truncMarek Olsak2015-10-292-6/+6
| | | | llvm-svn: 251630
* [mips] wrong opcode for ll/sc instructions on mipsr6 when -integrated-as is usedZoran Jovanovic2015-10-292-5/+42
| | | | | | | | | | | | | | | Summary: This commit resolves wrong opcodes for ll and sc instructions for r6 architecutres, which were generated in method MipsTargetLowering::emitAtomicBinary. Author: Jelena.Losic Reviewers: dsanders Subscribers: dsanders, llvm-commits Differential Revision: http://reviews.llvm.org/D13593 llvm-svn: 251629
* Fixup lldb-argdumper cmake buildPavel Labath2015-10-291-1/+1
| | | | | | forgot to rename in one spot. llvm-svn: 251628
* Recognize that ARM1176JZ[F]-S support TrustZoneArtyom Skrobov2015-10-294-2/+7
| | | | | | | | | | | | | | Summary: ARMv6KZ cores were set up incorrectly in ARM.td; also, the SMI mnemonic (the old name for SMC, as defined in ARMv6KZ) wasn't supported. Reviewers: jmolloy, rengolin Subscribers: aemerson, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D14154 llvm-svn: 251627
* Fix flakyness in TestChangeProcessGroupPavel Labath2015-10-291-3/+8
| | | | | | | | | | | The test was verifying that the pid of the child is not equal to its process group by searching for text substrings. This failed in the rare cases when the pid actually *was* a substring of the process group (even though they were not equal). Change the test to use SB API and do proper numeric comparisons. llvm-svn: 251626
* [compiler-rt] [msan] Unify aarch64 mappingAdhemerval Zanella2015-10-296-68/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch unify the 39-bit and 42-bit mapping for aarch64 to use only one instrumentation algorithm. A runtime check avoid mapping 42-bit only segments for 39-bit kernels. The mapping to use now is for 39 and 42-bits: 0x00000000000ULL-0x01000000000ULL MappingDesc::INVALID 0x01000000000ULL-0x02000000000ULL MappingDesc::SHADOW 0x02000000000ULL-0x03000000000ULL MappingDesc::ORIGIN 0x03000000000ULL-0x04000000000ULL MappingDesc::SHADOW 0x04000000000ULL-0x05000000000ULL MappingDesc::ORIGIN 0x05000000000ULL-0x06000000000ULL MappingDesc::APP 0x06000000000ULL-0x07000000000ULL MappingDesc::INVALID 0x07000000000ULL-0x08000000000ULL MappingDesc::APP And only for 42-bits: 0x08000000000ULL-0x09000000000ULL MappingDesc::INVALID 0x09000000000ULL-0x0A000000000ULL MappingDesc::SHADOW 0x0A000000000ULL-0x0B000000000ULL MappingDesc::ORIGIN 0x0B000000000ULL-0x0F000000000ULL MappingDesc::INVALID 0x0F000000000ULL-0x10000000000ULL MappingDesc::APP 0x10000000000ULL-0x11000000000ULL MappingDesc::INVALID 0x11000000000ULL-0x12000000000ULL MappingDesc::APP 0x12000000000ULL-0x17000000000ULL MappingDesc::INVALID 0x17000000000ULL-0x18000000000ULL MappingDesc::SHADOW 0x18000000000ULL-0x19000000000ULL MappingDesc::ORIGIN 0x19000000000ULL-0x20000000000ULL MappingDesc::INVALID 0x20000000000ULL-0x21000000000ULL MappingDesc::APP 0x21000000000ULL-0x26000000000ULL MappingDesc::INVALID 0x26000000000ULL-0x27000000000ULL MappingDesc::SHADOW 0x27000000000ULL-0x28000000000ULL MappingDesc::ORIGIN 0x28000000000ULL-0x29000000000ULL MappingDesc::SHADOW 0x29000000000ULL-0x2A000000000ULL MappingDesc::ORIGIN 0x2A000000000ULL-0x2B000000000ULL MappingDesc::APP 0x2B000000000ULL-0x2C000000000ULL MappingDesc::INVALID 0x2C000000000ULL-0x2D000000000ULL MappingDesc::SHADOW 0x2D000000000ULL-0x2E000000000ULL MappingDesc::ORIGIN 0x2E000000000ULL-0x2F000000000ULL MappingDesc::APP 0x2F000000000ULL-0x39000000000ULL MappingDesc::INVALID 0x39000000000ULL-0x3A000000000ULL MappingDesc::SHADOW 0x3A000000000ULL-0x3B000000000ULL MappingDesc::ORIGIN 0x3B000000000ULL-0x3C000000000ULL MappingDesc::APP 0x3C000000000ULL-0x3D000000000ULL MappingDesc::INVALID 0x3D000000000ULL-0x3E000000000ULL MappingDesc::SHADOW 0x3E000000000ULL-0x3F000000000ULL MappingDesc::ORIGIN 0x3F000000000ULL-0x40000000000ULL MappingDesc::APP And although complex it provides a better memory utilization that previous one. [1] http://reviews.llvm.org/D13817 llvm-svn: 251625
* [sanitizer] [msan] Unify aarch64 mappingAdhemerval Zanella2015-10-291-21/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch unify the 39-bit and 42-bit mapping for aarch64 to use only one instrumentation algorithm. This removes compiler flag SANITIZER_AARCH64_VMA requirement for MSAN on aarch64. The mapping to use now is for 39 and 42-bits: 0x00000000000ULL-0x01000000000ULL MappingDesc::INVALID 0x01000000000ULL-0x02000000000ULL MappingDesc::SHADOW 0x02000000000ULL-0x03000000000ULL MappingDesc::ORIGIN 0x03000000000ULL-0x04000000000ULL MappingDesc::SHADOW 0x04000000000ULL-0x05000000000ULL MappingDesc::ORIGIN 0x05000000000ULL-0x06000000000ULL MappingDesc::APP 0x06000000000ULL-0x07000000000ULL MappingDesc::INVALID 0x07000000000ULL-0x08000000000ULL MappingDesc::APP And only for 42-bits: 0x08000000000ULL-0x09000000000ULL MappingDesc::INVALID 0x09000000000ULL-0x0A000000000ULL MappingDesc::SHADOW 0x0A000000000ULL-0x0B000000000ULL MappingDesc::ORIGIN 0x0B000000000ULL-0x0F000000000ULL MappingDesc::INVALID 0x0F000000000ULL-0x10000000000ULL MappingDesc::APP 0x10000000000ULL-0x11000000000ULL MappingDesc::INVALID 0x11000000000ULL-0x12000000000ULL MappingDesc::APP 0x12000000000ULL-0x17000000000ULL MappingDesc::INVALID 0x17000000000ULL-0x18000000000ULL MappingDesc::SHADOW 0x18000000000ULL-0x19000000000ULL MappingDesc::ORIGIN 0x19000000000ULL-0x20000000000ULL MappingDesc::INVALID 0x20000000000ULL-0x21000000000ULL MappingDesc::APP 0x21000000000ULL-0x26000000000ULL MappingDesc::INVALID 0x26000000000ULL-0x27000000000ULL MappingDesc::SHADOW 0x27000000000ULL-0x28000000000ULL MappingDesc::ORIGIN 0x28000000000ULL-0x29000000000ULL MappingDesc::SHADOW 0x29000000000ULL-0x2A000000000ULL MappingDesc::ORIGIN 0x2A000000000ULL-0x2B000000000ULL MappingDesc::APP 0x2B000000000ULL-0x2C000000000ULL MappingDesc::INVALID 0x2C000000000ULL-0x2D000000000ULL MappingDesc::SHADOW 0x2D000000000ULL-0x2E000000000ULL MappingDesc::ORIGIN 0x2E000000000ULL-0x2F000000000ULL MappingDesc::APP 0x2F000000000ULL-0x39000000000ULL MappingDesc::INVALID 0x39000000000ULL-0x3A000000000ULL MappingDesc::SHADOW 0x3A000000000ULL-0x3B000000000ULL MappingDesc::ORIGIN 0x3B000000000ULL-0x3C000000000ULL MappingDesc::APP 0x3C000000000ULL-0x3D000000000ULL MappingDesc::INVALID 0x3D000000000ULL-0x3E000000000ULL MappingDesc::SHADOW 0x3E000000000ULL-0x3F000000000ULL MappingDesc::ORIGIN 0x3F000000000ULL-0x40000000000ULL MappingDesc::APP And although complex it provides a better memory utilization that previous one. llvm-svn: 251624
* Fix use-after-free. Thanks ASAN for giving me a detailed report :-).Daniel Jasper2015-10-291-2/+2
| | | | llvm-svn: 251623
* [mips] Check the register class before replacing materializations of zero ↵Vasileios Kalintiris2015-10-292-0/+13
| | | | | | | | | | | | | | | | | | | | | | with $zero in microMIPS. Summary: The microMIPS register class GPRMM16 does not contain the $zero register. However, MipsSEDAGToDAGISel::replaceUsesWithZeroReg() would replace uses of the $dst register: [d]addiu, $dst, $zero, 0 with the $zero register, without checking for membership in the register class of the target machine operand. Reviewers: dsanders Subscribers: llvm-commits, dsanders Differential Revision: http://reviews.llvm.org/D13984 llvm-svn: 251622
* [Analyzer] Widening loops which do not exitSean Eveson2015-10-299-3/+332
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Dear All, We have been looking at the following problem, where any code after the constant bound loop is not analyzed because of the limit on how many times the same block is visited, as described in bugzillas #7638 and #23438. This problem is of interest to us because we have identified significant bugs that the checkers are not locating. We have been discussing a solution involving ranges as a longer term project, but I would like to propose a patch to improve the current implementation. Example issue: ``` for (int i = 0; i < 1000; ++i) {...something...} int *p = 0; *p = 0xDEADBEEF; ``` The proposal is to go through the first and last iterations of the loop. The patch creates an exploded node for the approximate last iteration of constant bound loops, before the max loop limit / block visit limit is reached. It does this by identifying the variable in the loop condition and finding the value which is “one away” from the loop being false. For example, if the condition is (x < 10), then an exploded node is created where the value of x is 9. Evaluating the loop body with x = 9 will then result in the analysis continuing after the loop, providing x is incremented. The patch passes all the tests, with some modifications to coverage.c, in order to make the ‘function_which_gives_up’ continue to give up, since the changes allowed the analysis to progress past the loop. This patch does introduce possible false positives, as a result of not knowing the state of variables which might be modified in the loop. I believe that, as a user, I would rather have false positives after loops than do no analysis at all. I understand this may not be the common opinion and am interested in hearing your views. There are also issues regarding break statements, which are not considered. A more advanced implementation of this approach might be able to consider other conditions in the loop, which would allow paths leading to breaks to be analyzed. Lastly, I have performed a study on large code bases and I think there is little benefit in having “max-loop” default to 4 with the patch. For variable bound loops this tends to result in duplicated analysis after the loop, and it makes little difference to any constant bound loop which will do more than a few iterations. It might be beneficial to lower the default to 2, especially for the shallow analysis setting. Please let me know your opinions on this approach to processing constant bound loops and the patch itself. Regards, Sean Eveson SN Systems - Sony Computer Entertainment Group Reviewers: jordan_rose, krememek, xazax.hun, zaks.anna, dcoughlin Subscribers: krememek, xazax.hun, cfe-commits Differential Revision: http://reviews.llvm.org/D12358 llvm-svn: 251621
* [MachineVerifier] Analyze MachineMemOperands for mem-to-mem moves.Jonas Paulsson2015-10-292-7/+26
| | | | | | | | | | | | | Since the verifier will give false reports if it incorrectly thinks MI is loading or storing using an FI, it is necessary to scan memoperands and find out how the FI is used in the instruction. This should be relatively rare. Needed to make CodeGen/SystemZ/spill-01.ll pass, which now runs with this flag. Reviewed by Quentin Colombet. llvm-svn: 251620
* OrcJITTests: Update libdeps corresponding to r251604.NAKAMURA Takumi2015-10-291-0/+2
| | | | llvm-svn: 251619
* Implement P0004R1 'Remove Deprecated iostreams aliases'Marshall Clow2015-10-297-7/+35
| | | | llvm-svn: 251618
* Revert the revision 251592 as it fails a test on some platforms.Cong Hou2015-10-293-143/+32
| | | | llvm-svn: 251617
* Rename argdumper to lldb-argdumperTodd Fiala2015-10-296-35/+35
| | | | | | http://reviews.llvm.org/D14169 llvm-svn: 251616
* Revert "ScheduleDAGInstrs: Remove IsPostRA flag"Matthias Braun2015-10-294-22/+38
| | | | | | | | It broke 3 arm testcases. This reverts commit r251608. llvm-svn: 251615
* Fix an unused variable warning which broke the clang-cmake-mips builderPhilip Reames2015-10-291-1/+1
| | | | llvm-svn: 251614
* [WebAssembly] Update opcode name format for conversionsJF Bastien2015-10-293-48/+56
| | | | | | | | | | | | Summary: Conversion opcode name format should be f64.convert_u/i64 not f64_convert_u Author: s3ththompson Reviewers: jfb Subscribers: sunfish, jfb, llvm-commits, dschuff Differential Revision: http://reviews.llvm.org/D14160 llvm-svn: 251613
* [PGO] Do not emit runtime hook user function for LinuxXinliang David Li2015-10-292-15/+23
| | | | | | | | | | Clang driver now injects -u<hook_var> flag in the linker command line, in which case user function is not needed any more. Differential Revision: http://reviews.llvm.org/D14033 llvm-svn: 251612
* Fix a soon to be invalid testXinliang David Li2015-10-291-1/+0
| | | | | | | Remove a check that won't be valid when LLVM stops emitting runtime hook user function. llvm-svn: 251611
* [lld][MachO] Use a std::string rather than a StringRef for the section name inLang Hames2015-10-291-1/+1
| | | | | | | | | MachODefinedCustomSectionAtom. The section names for these atoms are initialized from temporaries (e.g. segName + "/" + sectName), so we can't use StringRef here. llvm-svn: 251610
* MachineScheduler: Fix typo in debug messageMatthias Braun2015-10-291-1/+1
| | | | | | Maybe I just missed the humor there ;-) llvm-svn: 251609
* ScheduleDAGInstrs: Remove IsPostRA flagMatthias Braun2015-10-294-38/+22
| | | | | | | | This was a layering violation in ScheduleDAGInstrs (and MachineSchedulerBase) they both shouldn't know directly whether they are used by the PostMachineScheduler or the MachineScheduler. llvm-svn: 251608
* MachineScheduler: Use ranged for and slightly simplify the codeMatthias Braun2015-10-291-11/+12
| | | | llvm-svn: 251607
* [LVI/CVP] Teach LVI about range metadataPhilip Reames2015-10-293-26/+56
| | | | | | | | | | | | | | Somewhat shockingly for an analysis pass which is computing constant ranges, LVI did not understand the ranges provided by range metadata. As part of this change, I included a change to CVP primarily because doing so made it much easier to write small self contained test cases. CVP was previously only handling the non-local operand case, but given that LVI can sometimes figure out information about instructions standalone, I don't see any reason to restrict this. There could possibly be a compile time impact from this, but I suspect it should be minimal. If anyone has an example which substaintially regresses, please let me know. I could restrict the block local handling to ICmps feeding Terminator instructions if needed. Note that this patch continues a somewhat bad practice in LVI. In many cases, we know facts about values, and separate context sensitive facts about values. LVI makes no effort to distinguish and will frequently cache the same value fact repeatedly for different contexts. I would like to change this, but that's a large enough change that I want it to go in separately with clear documentation of what's changing. Other examples of this include the non-null handling, and arguments. As a meta comment: the entire motivation of this change was being able to write smaller (aka reasonable sized) test cases for a future patch teaching LVI about select instructions. Differential Revision: http://reviews.llvm.org/D13543 llvm-svn: 251606
* [Orc] Add missing file for r251604.Lang Hames2015-10-291-0/+94
| | | | llvm-svn: 251605
* [Orc] Add support for RuntimeDyld::setProcessAllSections.Lang Hames2015-10-293-9/+33
| | | | llvm-svn: 251604
* test: fix overzealous matchSaleem Abdulrasool2015-10-291-1/+1
| | | | | | Accidentally made the test too strict. llvm-svn: 251603
* Driver: CrossWindows sanitizers link supportSaleem Abdulrasool2015-10-292-0/+29
| | | | | | | Add the required libraries to the linker invocation when building with sanitizers. llvm-svn: 251600
* Driver: inline some small arraysSaleem Abdulrasool2015-10-291-10/+4
| | | | | | Use an initializer list to remove a couple of small static arrays. NFC. llvm-svn: 251599
* Driver: tweak CrossWindows sanitizer supportSaleem Abdulrasool2015-10-293-0/+20
| | | | | | | Indicate support for ASAN on the CrossWindows toolchain. Although this is insufficient, this at least permits the handling of the driver flag. llvm-svn: 251598
* [InstSimplify] sgt on i1s also encodes implicationPhilip Reames2015-10-292-0/+22
| | | | | | | | | | | | | | | Follow on to http://reviews.llvm.org/D13074, implementing something pointed out by Sanjoy. His truth table from his comment on that bug summarizes things well: LHS | RHS | LHS >=s RHS | LHS implies RHS 0 | 0 | 1 (0 >= 0) | 1 0 | 1 | 1 (0 >= -1) | 1 1 | 0 | 0 (-1 >= 0) | 0 1 | 1 | 1 (-1 >= -1) | 1 The key point is that an "i1 1" is the value "-1", not "1". Differential Revision: http://reviews.llvm.org/D13756 llvm-svn: 251597
* [SimplifyCFG] Constant fold a branch implied by it's incoming edgePhilip Reames2015-10-292-0/+94
| | | | | | | | | | | The most common use case is when eliminating redundant range checks in an example like the following: c = a[i+1] + a[i]; Note that all the smarts of the transform (the implication engine) is already in ValueTracking and is tested directly through InstructionSimplify. Differential Revision: http://reviews.llvm.org/D13040 llvm-svn: 251596
* [SimplifyLibCalls] Factor out common unsafe-math checks.Davide Italiano2015-10-291-29/+23
| | | | llvm-svn: 251595
* Remove CRLF line endings.Benjamin Kramer2015-10-291-6/+6
| | | | llvm-svn: 251594
* Tweak test check pattern to fix bot failure.Diego Novillo2015-10-291-1/+1
| | | | llvm-svn: 251593
* Add a flag vectorizer-maximize-bandwidth in loop vectorizer to enable using ↵Cong Hou2015-10-293-32/+143
| | | | | | | | larger vectorization factor. To be able to maximize the bandwidth during vectorization, this patch provides a new flag vectorizer-maximize-bandwidth. When it is turned on, the vectorizer will determine the vectorization factor (VF) using the smallest instead of widest type in the loop. To avoid increasing register pressure too much, estimates of the register usage for different VFs are calculated so that we only choose a VF when its register usage doesn't exceed the number of available registers. llvm-svn: 251592
* [analyzer] Update analyzer website for release of checker-277.Devin Coughlin2015-10-294-3/+33
| | | | llvm-svn: 251591
* Leave TestAttachResume as flakey on linuxPavel Labath2015-10-291-0/+1
| | | | | | there must be (at least) one more race hidden there... llvm-svn: 251590
OpenPOWER on IntegriCloud