summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/FaultMaps.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [FaultMaps] Make label formation a bit more explicit [NFC]Philip Reames2019-12-191-3/+1
| | | | This is in advance of assembler padding directives support where we'll need to bundle the label w/the corresponding faulting instruction to avoid padding being inserted between.
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-11/+11
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-02-271-5/+6
| | | | | | other minor fixes (NFC). llvm-svn: 296404
* [ImplicitNullCheck] Extend Implicit Null Check scope by using storesSanjoy Das2017-02-071-0/+4
| | | | | | | | | | | | | | | | | | | | | Summary: This change allows usage of store instruction for implicit null check. Memory Aliasing Analisys is not used and change conservatively supposes that any store and load may access the same memory. As a result re-ordering of store-store, store-load and load-store is prohibited. Patch by Serguei Katkov! Reviewers: reames, sanjoy Reviewed By: sanjoy Subscribers: atrick, llvm-commits Differential Revision: https://reviews.llvm.org/D29400 llvm-svn: 294338
* Revert "[FaultMaps] Move FaultMapParser to Object/"Sanjoy Das2015-06-231-0/+36
| | | | | | | This reverts commit r240364 (git c49542e5bb186). The issue r240364 was trying to fix was fixed independently in r240362. llvm-svn: 240448
* [FaultMaps] Move FaultMapParser to Object/Sanjoy Das2015-06-231-36/+0
| | | | | | | | | | | | | | | | | | Summary: That way llvm-objdump can rely on it without adding an extra dependency on CodeGen. This change duplicates the FaultKind enum and the code that serializes it to a string. I could not figure out a way to get around this without adding a new dependency to Object Reviewers: rafael, ab Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10619 llvm-svn: 240364
* Fix MSVC build.Sanjoy Das2015-06-221-4/+3
| | | | | | | | I had some unnecessary `typename`s left in after addressing review. This compiled successfully with clang++ but MSVC reported an error. Fix the build error by removing the redundant `typename`s. llvm-svn: 240307
* [FaultMaps] Add a parser for the __llvm__faultmaps section.Sanjoy Das2015-06-221-0/+37
| | | | | | | | | | | | | | | Summary: The parser is exercised by llvm-objdump using -print-fault-maps. As is probably obvious, the code itself was "heavily inspired" by http://reviews.llvm.org/D10434. Reviewers: reames, atrick, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10491 llvm-svn: 240304
* Unbreak the build from r239740.Sanjoy Das2015-06-151-4/+4
| | | | | | Do not re-use an enum name as a field name. Some bots don't like this. llvm-svn: 239746
* [CodeGen] Introduce a FAULTING_LOAD_OP pseudo-op.Sanjoy Das2015-06-151-0/+114
Summary: This instruction encodes a loading operation that may fault, and a label to branch to if the load page-faults. The locations of potentially faulting loads and their "handler" destinations are recorded in a FaultMap section, meant to be consumed by LLVM's clients. Nothing generates FAULTING_LOAD_OP instructions yet, but they will be used in a future change. The documentation (FaultMaps.rst) needs improvement and I will update this diff with a more expanded version shortly. Depends on D10196 Reviewers: rnk, reames, AndyAyers, ab, atrick, pgavlin Reviewed By: atrick, pgavlin Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10197 llvm-svn: 239740
OpenPOWER on IntegriCloud