summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-cov] Add the project summary to each source file coverage report.Ying Yi2016-08-2412-40/+254
| | | | | | | | | | | | This patch includes the following changes: - Included header "Code coverage report" and include the date that the report was created. - Included title (as specified in a command line option, (i.e llvm-cov -project-title="Simple Test") - In the summary, list the elf files that the source code file has contributed to. - Used column heading for "Line No.", "Count No.", Source". Differential Revision: https://reviews.llvm.org/D23345 llvm-svn: 279628
* Fix mismatched new/free in Process:RunPrivateStateThreadPavel Labath2016-08-241-3/+2
| | | | | | NFC llvm-svn: 279627
* [InstCombine] add assert and explanatory comment for fold removed in ↵Sanjay Patel2016-08-241-0/+7
| | | | | | | | | | | | | | | | r279568; NFC I deleted a fold from InstCombine at: https://reviews.llvm.org/rL279568 because it (like any InstCombine to a constant?) should always happen in InstSimplify, however, it's not obvious what the assumptions are in the remaining code. Add a comment and assert to make it clearer. Differential Revision: https://reviews.llvm.org/D23819 llvm-svn: 279626
* Create subranges for new intervals resulting from live interval splittingKrzysztof Parzyszek2016-08-2417-167/+963
| | | | | | | | | | | | | | | | | | | The register allocator can split a live interval of a register into a set of smaller intervals. After the allocation of registers is complete, the rewriter will modify the IR to replace virtual registers with the corres- ponding physical registers. At this stage, if a register corresponding to a subregister of a virtual register is used, the rewriter will check if that subregister is undefined, and if so, it will add the <undef> flag to the machine operand. The function verifying liveness of the subregis- ter would assume that it is undefined, unless any of the subranges of the live interval proves otherwise. The problem is that the live intervals created during splitting do not have any subranges, even if the original parent interval did. This could result in the <undef> flag placed on a register that is actually defined. Differential Revision: http://reviews.llvm.org/D21189 llvm-svn: 279625
* [mips] Preparatory work for a generic schedulerSimon Dardis2016-08-2423-423/+629
| | | | | | | | | | | | | Extend instruction definitions from nearly all ISAs to include appropriate instruction itineraries. Change MIPS16s gp prologue generation to use real instructions instead of using a pseudo instruction. Reviewers: dsanders, vkalintiris Differential Review: https://reviews.llvm.org/D23548 llvm-svn: 279623
* [X86][AVX2] Ensure on 32-bit targets that we broadcast f64 types not i64 ↵Simon Pilgrim2016-08-242-9/+53
| | | | | | (PR29101) llvm-svn: 279622
* [X86][F16C] Regenerated f16c testsSimon Pilgrim2016-08-242-44/+119
| | | | llvm-svn: 279621
* [Loop Vectorizer] Support predication of div/remGil Rapaport2016-08-244-100/+501
| | | | | | | | | | div/rem instructions in basic blocks that require predication currently prevent vectorization. This patch extends the existing mechanism for predicating stores to handle other instructions and leverages it to predicate divs and rems. Differential Revision: https://reviews.llvm.org/D22918 llvm-svn: 279620
* [X86][SSE] Add support for 32-bit element vectors to X86ISD::VZEXT_LOADSimon Pilgrim2016-08-243-23/+33
| | | | | | | | | | | | | | Consecutive load matching (EltsFromConsecutiveLoads) currently uses VZEXT_LOAD (load scalar into lowest element and zero uppers) for vXi64 / vXf64 vectors only. For vXi32 / vXf32 vectors it instead creates a scalar load, SCALAR_TO_VECTOR and finally VZEXT_MOVL (zero upper vector elements), relying on tablegen patterns to match this into an equivalent of VZEXT_LOAD. This patch adds the VZEXT_LOAD patterns for vXi32 / vXf32 vectors directly and updates EltsFromConsecutiveLoads to use this. This has proven necessary to allow us to easily make VZEXT_MOVL a full member of the target shuffle set - without this change the call to combineShuffle (which is the main caller of EltsFromConsecutiveLoads) tended to recursively recreate VZEXT_MOVL nodes...... Differential Revision: https://reviews.llvm.org/D23673 llvm-svn: 279619
* [PM] Introduce basic update capabilities to the new PM's CGSCC passChandler Carruth2016-08-2413-111/+1278
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | manager, including both plumbing and logic to handle function pass updates. There are three fundamentally tied changes here: 1) Plumbing *some* mechanism for updating the CGSCC pass manager as the CG changes while passes are running. 2) Changing the CGSCC pass manager infrastructure to have support for the underlying graph to mutate mid-pass run. 3) Actually updating the CG after function passes run. I can separate them if necessary, but I think its really useful to have them together as the needs of #3 drove #2, and that in turn drove #1. The plumbing technique is to extend the "run" method signature with extra arguments. We provide the call graph that intrinsically is available as it is the basis of the pass manager's IR units, and an output parameter that records the results of updating the call graph during an SCC passes's run. Note that "...UpdateResult" isn't a *great* name here... suggestions very welcome. I tried a pretty frustrating number of different data structures and such for the innards of the update result. Every other one failed for one reason or another. Sometimes I just couldn't keep the layers of complexity right in my head. The thing that really worked was to just directly provide access to the underlying structures used to walk the call graph so that their updates could be informed by the *particular* nature of the change to the graph. The technique for how to make the pass management infrastructure cope with mutating graphs was also something that took a really, really large number of iterations to get to a place where I was happy. Here are some of the considerations that drove the design: - We operate at three levels within the infrastructure: RefSCC, SCC, and Node. In each case, we are working bottom up and so we want to continue to iterate on the "lowest" node as the graph changes. Look at how we iterate over nodes in an SCC running function passes as those function passes mutate the CG. We continue to iterate on the "lowest" SCC, which is the one that continues to contain the function just processed. - The call graph structure re-uses SCCs (and RefSCCs) during mutation events for the *highest* entry in the resulting new subgraph, not the lowest. This means that it is necessary to continually update the current SCC or RefSCC as it shifts. This is really surprising and subtle, and took a long time for me to work out. I actually tried changing the call graph to provide the opposite behavior, and it breaks *EVERYTHING*. The graph update algorithms are really deeply tied to this particualr pattern. - When SCCs or RefSCCs are split apart and refined and we continually re-pin our processing to the bottom one in the subgraph, we need to enqueue the newly formed SCCs and RefSCCs for subsequent processing. Queuing them presents a few challenges: 1) SCCs and RefSCCs use wildly different iteration strategies at a high level. We end up needing to converge them on worklist approaches that can be extended in order to be able to handle the mutations. 2) The order of the enqueuing need to remain bottom-up post-order so that we don't get surprising order of visitation for things like the inliner. 3) We need the worklists to have set semantics so we don't duplicate things endlessly. We don't need a *persistent* set though because we always keep processing the bottom node!!!! This is super, super surprising to me and took a long time to convince myself this is correct, but I'm pretty sure it is... Once we sink down to the bottom node, we can't re-split out the same node in any way, and the postorder of the current queue is fixed and unchanging. 4) We need to make sure that the "current" SCC or RefSCC actually gets enqueued here such that we re-visit it because we continue processing a *new*, *bottom* SCC/RefSCC. - We also need the ability to *skip* SCCs and RefSCCs that get merged into a larger component. We even need the ability to skip *nodes* from an SCC that are no longer part of that SCC. This led to the design you see in the patch which uses SetVector-based worklists. The RefSCC worklist is always empty until an update occurs and is just used to handle those RefSCCs created by updates as the others don't even exist yet and are formed on-demand during the bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and we push new SCCs onto it and blacklist existing SCCs on it to get the desired processing. We then *directly* update these when updating the call graph as I was never able to find a satisfactory abstraction around the update strategy. Finally, we need to compute the updates for function passes. This is mostly used as an initial customer of all the update mechanisms to drive their design to at least cover some real set of use cases. There are a bunch of interesting things that came out of doing this: - It is really nice to do this a function at a time because that function is likely hot in the cache. This means we want even the function pass adaptor to support online updates to the call graph! - To update the call graph after arbitrary function pass mutations is quite hard. We have to build a fairly comprehensive set of data structures and then process them. Fortunately, some of this code is related to the code for building the cal graph in the first place. Unfortunately, very little of it makes any sense to share because the nature of what we're doing is so very different. I've factored out the one part that made sense at least. - We need to transfer these updates into the various structures for the CGSCC pass manager. Once those were more sanely worked out, this became relatively easier. But some of those needs necessitated changes to the LazyCallGraph interface to make it significantly easier to extract the changed SCCs from an update operation. - We also need to update the CGSCC analysis manager as the shape of the graph changes. When an SCC is merged away we need to clear analyses associated with it from the analysis manager which we didn't have support for in the analysis manager infrsatructure. New SCCs are easy! But then we have the case that the original SCC has its shape changed but remains in the call graph. There we need to *invalidate* the analyses associated with it. - We also need to invalidate analyses after we *finish* processing an SCC. But the analyses we need to invalidate here are *only those for the newly updated SCC*!!! Because we only continue processing the bottom SCC, if we split SCCs apart the original one gets invalidated once when its shape changes and is not processed farther so its analyses will be correct. It is the bottom SCC which continues being processed and needs to have the "normal" invalidation done based on the preserved analyses set. All of this is mostly background and context for the changes here. Many thanks to all the reviewers who helped here. Especially Sanjoy who caught several interesting bugs in the graph algorithms, David, Sean, and others who all helped with feedback. Differential Revision: http://reviews.llvm.org/D21464 llvm-svn: 279618
* Canonicalize output section name for .ARM.exidx sectionsPeter Smith2016-08-242-1/+51
| | | | | | | | | | | | | | | | | | The ARM Exception handling ABI requires that all ARM exception index table sections have a prefix of .ARM.exidx and are combined into a single contiguous block either in their own output section or as part of another output section. In general clang will output a single .ARM.exidx section per object, but will use .ARM.exidx.<section name> when -ffunction-sections is used. This change canonicalizes the names of sections with the .ARM.exidx prefix to just .ARM.exidx, which ensures that there is only a single output section. Differential Revision: https://reviews.llvm.org/D23775 llvm-svn: 279617
* [asan] Mark asan-symbolize-sanity-test.cc as UNSUPPORTED on x86_64-appleAkira Hatanaka2016-08-241-0/+1
| | | | | | | | | | | | | | | | | and x86_64h-apple. Mark the test as UNSUPPORTED to fix a bot that is failing. http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check The bot is failing because asan_symbolize.py cannot tell whether the reported address is from an x86_64 slice or an x86_64h slice by the length of the address alone, so it ends up passing the wrong arch to atos. rdar://problem/27907889 llvm-svn: 279614
* [AST] Make InitListExpr::isExplicit const (NFC)Vedant Kumar2016-08-241-1/+1
| | | | | | | | Patch by Alexander Shaposhnikov! Differential Revision: https://reviews.llvm.org/D23828 llvm-svn: 279613
* Tentatively fix gold-plugin test: ThinLTO objects start at offset 0 now.Mehdi Amini2016-08-241-1/+1
| | | | | | Annoyingly, incremental builds don't detect these kind of issue. llvm-svn: 279612
* Add api logging for SBDebugger::SetCurrentPlatformSDKRoot.Jason Molenda2016-08-241-0/+3
| | | | | | <rdar://problem/27857025> llvm-svn: 279611
* [Coroutines] Fix unused var warning in release buildGor Nishanov2016-08-241-2/+2
| | | | llvm-svn: 279610
* [Coroutines] Part 8: Coroutine Frame Building algorithmGor Nishanov2016-08-244-8/+659
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds coroutine frame building algorithm. Now, simple coroutines such as ex0.ll and ex1.ll (first examples from docs\Coroutines.rst can be compiled). Documentation and overview is here: http://llvm.org/docs/Coroutines.html. Upstreaming sequence (rough plan) 1.Add documentation. (https://reviews.llvm.org/D22603) 2.Add coroutine intrinsics. (https://reviews.llvm.org/D22659) ... 7. Split coroutine into subfunctions. (https://reviews.llvm.org/D23461) 8. Coroutine Frame Building algorithm <= we are here 9. Add f.cleanup subfunction. 10+. The rest of the logic Reviewers: majnemer Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23586 llvm-svn: 279609
* [Pragma] Clear loop distribution attribute between loopsAdam Nemet2016-08-242-0/+24
| | | | llvm-svn: 279608
* Remove excessive padding from PTHStatData (NFC)Mehdi Amini2016-08-241-2/+2
| | | | | | | | | | | | | This diff reorders the fields and removes excessive padding. This fixes the following warning: PTHLexer.cpp:629:7: warning: Excessive padding in 'class (anonymous namespace)::PTHStatData' (14 padding bytes, where 6 is optimal). Optimal fields order: Size, ModTime, UniqueID, HasData, IsDirectory, consider reordering the fields or adding explicit padding members. Patch by: Alexander Shaposhnikov <shal1t712@gmail.com> Differential Revision: https://reviews.llvm.org/D23826 llvm-svn: 279607
* libc++: add an option to build against compiler-rtSaleem Abdulrasool2016-08-242-1/+8
| | | | | | This mirrors the option in libc++abi to build without libgcc. llvm-svn: 279606
* Preserve a pointer to the newly allocated signal stack as well. That tooChandler Carruth2016-08-241-4/+6
| | | | | | is flagged by LSan at least among leak detectors. llvm-svn: 279605
* TargetSchedule: Do not consider subregister definitions as reads.Matthias Braun2016-08-241-1/+1
| | | | | | | | | | | | | | We should not consider subregister definitions as reads for schedule model purposes (they are just modeled as reads of the overal vreg for liveness calculation purposes, the CPU instructions are not actually reading). Unfortunately I cannot submit a test for this as it requires a target which uses ReadAdvance annotation in the scheduling model and has subregister liveness enabled at the same time, which is only the case on an out of tree target. llvm-svn: 279604
* Adding an additional test to ensure the frame pointer is emittedDouglas Yung2016-08-241-0/+2
| | | | | | when compiling with optimization when PS4 is the target. llvm-svn: 279603
* CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePassesMatthias Braun2016-08-2424-162/+109
| | | | | | | | | | | | | | | | | | | | | | Re-apply this patch, hopefully I will get away without any warnings in the constructor now. This patch removes the MachineFunctionAnalysis. Instead we keep a map from IR Function to MachineFunction in the MachineModuleInfo. This allows the insertion of ModulePasses into the codegen pipeline without breaking it because the MachineFunctionAnalysis gets dropped before a module pass. Peak memory should stay unchanged without a ModulePass in the codegen pipeline: Previously the MachineFunction was freed at the end of a codegen function pipeline because the MachineFunctionAnalysis was dropped; With this patch the MachineFunction is freed after the AsmPrinter has finished. Differential Revision: http://reviews.llvm.org/D23736 llvm-svn: 279602
* [libFuzzer] use __attribute__((target("popcnt"))) only on x86_64Kostya Serebryany2016-08-244-7/+13
| | | | llvm-svn: 279601
* MIRParser/MIRPrinter: Compute isSSA instead of printing/parsing it.Matthias Braun2016-08-2470-160/+21
| | | | | | | | | Specifying isSSA is an extra line at best and results in invalid MI at worst. Compute the value instead. Differential Revision: http://reviews.llvm.org/D22722 llvm-svn: 279600
* Increase the size of the sigaltstack used by LLVM signal handlers. 8KB is notRichard Smith2016-08-241-1/+1
| | | | | | | | sufficient in some cases; increase to 64KB, which should be enough for anyone :) Patch by github.com/bryant! llvm-svn: 279599
* MachineModuleInfo: Avoid dummy constructor, use INITIALIZE_TM_PASSMatthias Braun2016-08-246-32/+13
| | | | | | | | | | | Change this pass constructor to just accept a const TargetMachine * and use INITIALIZE_TM_PASS, that way we can get rid of the dummy constructor. The pass will still fail when calling the default constructor leading to TM == nullptr, this is no different than before but is more in line what other codegen passes are doing and avoids the dummy constructor. llvm-svn: 279598
* Revert "libc++: Perform configuration checks with -nodefaultlibs"Saleem Abdulrasool2016-08-241-21/+2
| | | | | | | This reverts SVN r279584 which broke the buildbots. Will re-apply once the issue has been root-caused and fixed. llvm-svn: 279596
* [sanitizer] trying to fix the PPC botsKostya Serebryany2016-08-241-1/+1
| | | | llvm-svn: 279595
* [ADCE] Add control dependence computationDavid Callahan2016-08-241-21/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is part of a serious of patches to evolve ADCE.cpp to support removing of unnecessary control flow. This patch adds the ability to compute control dependences using the iterated dominance frontier. We extend the liveness propagation to alternate between data and control dependences until convergences. Modify the pass manager intergation to compute the post-dominator tree needed for iterator dominance frontier. We still force all terminators live for now until we add code to handlinge removing control flow in a later patch. No changes to effective behavior with this patch Previous patches: D23225 [ADCE] Modify data structures to support removing control flow D23065 [ADCE] Refactor anticipating new functionality (NFC) D23102 [ADCE] Refactoring for new functionality (NFC) Reviewers: nadav, majnemer, mehdi_amini Subscribers: twoh, freik, llvm-commits Differential Revision: https://reviews.llvm.org/D23559 llvm-svn: 279594
* [stackmaps] Remove an unneeded member variable [NFC]Philip Reames2016-08-232-5/+3
| | | | llvm-svn: 279590
* [libFuzzer] fix link in docsKostya Serebryany2016-08-231-1/+1
| | | | llvm-svn: 279589
* [libFuzzer] collect 64 states for value profile, not 65Kostya Serebryany2016-08-231-1/+5
| | | | llvm-svn: 279588
* [libFuzzer] docs on value profileKostya Serebryany2016-08-231-0/+28
| | | | llvm-svn: 279587
* [stackmaps] More extraction of common code [NFCI]Philip Reames2016-08-236-24/+55
| | | | | | General cleanup before starting to work on the part I want to actually change. llvm-svn: 279586
* [LoopUnroll] By default disable unrolling when optimizing for size.Michael Zolotukhin2016-08-232-1/+9
| | | | | | | | | | | | | | | | | | | | | Summary: In clang commit r268509 we started to invoke loop-unroll pass from the driver even under -Os. However, we happen to not initialize optsize thresholds properly, which si fixed with this change. r268509 led to some big compile time regressions, because we started to unroll some loops that we didn't unroll before. With this change I hope to recover most of the regressions. We still are slightly slower than before, because we do some checks here and there in loop-unrolling before we bail out, but at least the slowdown is not that huge now. Reviewers: hfinkel, chandlerc Subscribers: mzolotukhin, llvm-commits Differential Revision: https://reviews.llvm.org/D23388 llvm-svn: 279585
* libc++: Perform configuration checks with -nodefaultlibsSaleem Abdulrasool2016-08-231-2/+21
| | | | | | | | | | | | | | | | | We're compiling libc++ with -nodefaultlibs, so we should also pass this option during the configuration checks to ensure those checks are consistent with the actual build. The primary motivation here is to ease cross-compilation against a non-standard set of C++ libraries. Previously, the configuration checks would attempt to link against the standard C++ libraries, which would cause link failures when cross-compiling, even though the actual library link would go through correctly (because of the use of -nodefaultlibs and explicitly specifying any needed libraries). This is more correct even ignoring the motivation, however. Patch by Shoaib Meenai! llvm-svn: 279584
* Don't use "return {...}" to initialize a std::tuple. This has only been validRichard Smith2016-08-231-2/+2
| | | | | | | | | since 2015 (n4387), though it's allowed by a library DR so new implementations accept it in their C++11 modes... This should unbreak the build with libstdc++ 4.9. llvm-svn: 279583
* #ifdef out validation code when asserts are disabled to remove unused variableRichard Smith2016-08-231-0/+2
| | | | | | warnings. llvm-svn: 279582
* Remove unused data member to unbreak -Werror builds.Richard Smith2016-08-232-5/+1
| | | | llvm-svn: 279581
* Revert r279564. It introduces undefined behavior (binding a reference to aRichard Smith2016-08-2325-115/+171
| | | | | | | dereferenced null pointer) in MachineModuleInfo::MachineModuleInfo that causes -Werror builds (including several buildbots) to fail. llvm-svn: 279580
* GlobalISel: add some G_TRUNCs to make icmp test valid MIR.Tim Northover2016-08-231-11/+17
| | | | llvm-svn: 279579
* [InstCombine] use local variables for repeated values; NFCISanjay Patel2016-08-231-12/+9
| | | | llvm-svn: 279578
* [MC] Support .dc directives in assembler parserPetr Hosek2016-08-232-0/+67
| | | | | | | | | | While these directives are mostly aliases for the existing integer and float value directives, some of them like .dc.a have no direct equivalents and are sometimes being used for convenience. Differential Revision: https://reviews.llvm.org/D23810 llvm-svn: 279577
* [ThinLTO] Add caching to the new LTO APIMehdi Amini2016-08-238-35/+393
| | | | | | | | | | | | Add the ability to plug a cache on the LTO API. I tried to write such that a linker implementation can control the cache backend. This is intrusive and I'm not totally happy with it, but I can't figure out a better design right now. Differential Revision: https://reviews.llvm.org/D23599 llvm-svn: 279576
* [InstCombine] move foldICmpShrConstConst() contents to foldICmpShrConst(); NFCISanjay Patel2016-08-232-77/+65
| | | | | | | There will only be 3 lines of code in foldICmpShrConst() when the cleanup is done, so it doesn't make much sense to have a separate function for a single fold. llvm-svn: 279575
* [stackmaps] Extract out magic constants [NFCI]Philip Reames2016-08-233-6/+40
| | | | | | This is a first step towards clarifying the exact MI semantics of stackmap's "live values". llvm-svn: 279574
* MachineFunction: Introduce NoPHIs propertyMatthias Braun2016-08-2310-4/+52
| | | | | | | | | | | | | I want to compute the SSA property of .mir files automatically in upcoming patches. The problem with this is that some inputs will be reported as static single assignment with some passes claiming not to support SSA form. In reality though those passes do not support PHI instructions => Track the presence of PHI instructions separate from the SSA property. Differential Revision: https://reviews.llvm.org/D22719 llvm-svn: 279573
* [sanitizer] change the 64-bit allocator to use a single array for free-d ↵Kostya Serebryany2016-08-233-182/+144
| | | | | | chunks instead of a lock-free linked list of tranfer batches. This change simplifies the code, makes the allocator more 'hardened', and will allow simpler code to release RAM to OS. This may also slowdown malloc stress tests due to lock contension, but I did not observe noticeable slowdown on various real multi-threaded benchmarks. llvm-svn: 279572
OpenPOWER on IntegriCloud