Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
#
05da2fe5 |
| 13-Nov-2019 |
Reid Kleckner <rnk@google.com> |
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of reco
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
show more ...
|
#
98603a81 |
| 08-Oct-2019 |
Nikola Prica <nikola.prica@rt-rk.com> |
[DebugInfo][If-Converter] Update call site info during the optimization
During the If-Converter optimization pay attention when copying or deleting call instructions in order to keep call site infor
[DebugInfo][If-Converter] Update call site info during the optimization
During the If-Converter optimization pay attention when copying or deleting call instructions in order to keep call site information in valid state.
Reviewers: aprantl, vsk, efriedma
Reviewed By: vsk, efriedma
Differential Revision: https://reviews.llvm.org/D66955
llvm-svn: 374068
show more ...
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4 |
|
#
71d3869f |
| 27-Jun-2019 |
Djordje Todorovic <djordje.todorovic@rt-rk.com> |
[Backend] Keep call site info valid through the backend
Handle call instruction replacements and deletions in order to preserve valid state of the call site info of the MachineFunction.
NOTE: If th
[Backend] Keep call site info valid through the backend
Handle call instruction replacements and deletions in order to preserve valid state of the call site info of the MachineFunction.
NOTE: If the call site info is enabled for a new target, the assertion from the MachineFunction::DeleteMachineInstr() should help to locate places where the updateCallSiteInfo() should be called in order to preserve valid state of the call site info.
([10/13] Introduce the debug entry values.)
Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com>
Differential Revision: https://reviews.llvm.org/D61062
llvm-svn: 364536
show more ...
|
Revision tags: llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo 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
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2 |
|
#
fb3f509e |
| 20-Mar-2018 |
Michael Zolotukhin <mzolotukhin@apple.com> |
[XRay] Lazily compute MachineLoopInfo instead of requiring it.
Summary: Currently X-Ray Instrumentation pass has a dependency on MachineLoopInfo (and thus on MachineDominatorTree as well) and we hav
[XRay] Lazily compute MachineLoopInfo instead of requiring it.
Summary: Currently X-Ray Instrumentation pass has a dependency on MachineLoopInfo (and thus on MachineDominatorTree as well) and we have to compute them even if X-Ray is not used. This patch changes it to a lazy computation to save compile time by avoiding these redundant computations.
Reviewers: dberris, kubamracek
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D44666
llvm-svn: 327999
show more ...
|
Revision tags: llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1 |
|
#
f1caa283 |
| 15-Dec-2017 |
Matthias Braun <matze@braunis.de> |
MachineFunction: Return reference from getFunction(); NFC
The Function can never be nullptr so we can return a reference.
llvm-svn: 320884
|
Revision tags: llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2 |
|
#
b3bde2ea |
| 17-Nov-2017 |
David Blaikie <dblaikie@gmail.com> |
Fix a bunch more layering of CodeGen headers that are in Target
All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, n
Fix a bunch more layering of CodeGen headers that are in Target
All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around).
llvm-svn: 318490
show more ...
|
#
3f833edc |
| 08-Nov-2017 |
David Blaikie <dblaikie@gmail.com> |
Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layering
This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the
Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layering
This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation.
llvm-svn: 317647
show more ...
|
Revision tags: llvmorg-5.0.1-rc1 |
|
#
cee75361 |
| 22-Sep-2017 |
Tim Shen <timshen91@gmail.com> |
[XRay] support conditional return on PPC.
Summary: Conditional returns were not taken into consideration at all. Implement them by turning them into jumps and normal returns. This means there is a s
[XRay] support conditional return on PPC.
Summary: Conditional returns were not taken into consideration at all. Implement them by turning them into jumps and normal returns. This means there is a slightly higher performance penalty for conditional returns, but this is the best we can do, and it still disturbs little of the rest.
Reviewers: dberris, echristo
Subscribers: sanjoy, nemanjai, hiraditya, kbarton, llvm-commits
Differential Revision: https://reviews.llvm.org/D38102
llvm-svn: 314005
show more ...
|
#
711dec26 |
| 08-Sep-2017 |
Dean Michael Berris <dberris@google.com> |
[XRay][CodeGen][PowerPC] Fix tail exit codegen for XRay in PPC
Summary: This fixes code-gen for XRay in PPC. The regression wasn't caught by codegen tests which we add in this change.
What happene
[XRay][CodeGen][PowerPC] Fix tail exit codegen for XRay in PPC
Summary: This fixes code-gen for XRay in PPC. The regression wasn't caught by codegen tests which we add in this change.
What happened was the following:
- For tail exits, we used to unconditionally prepend the returns/exits with a pseudo-instruction that gets lowered to the instrumentation sled (and leave the actual return/exit instruction as-is). - Changes to the XRay instrumentation pass caused the tail exits to suddenly also emit the tail exit pseudo-instruction, since the check for whether a return instruction was also a call instruction meant it was a tail exit instruction. - None of the tests caught the regression either due to non-existent tests, or the tests being disabled/removed for continuous breakage.
This change re-introduces some of the basic tests and verifies that we're back to a state that allows the back-end to generate appropriate XRay instrumented binaries for PPC in the presence of tail exits.
Reviewers: echristo, timshen
Subscribers: nemanjai, kbarton, llvm-commits
Differential Revision: https://reviews.llvm.org/D37570
llvm-svn: 312772
show more ...
|
Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1 |
|
#
e4b97459 |
| 14-Jul-2017 |
Dimitry Andric <dimitry@andric.com> |
Fix mixed line terminators. NFC.
llvm-svn: 308052
|
Revision tags: llvmorg-4.0.1, llvmorg-4.0.1-rc3 |
|
#
85427c0d |
| 09-Jun-2017 |
Serge Rogatch <srogatch@accesssoftek.com> |
[XRay] Fix computation of function size subject to XRay threshold
Summary: Currently XRay compares its threshold against `Function::size()` . However, `Function::size()` returns the number of basic
[XRay] Fix computation of function size subject to XRay threshold
Summary: Currently XRay compares its threshold against `Function::size()` . However, `Function::size()` returns the number of basic blocks (as I understand, such as cycle bodies, if/else bodies, switch-case bodies, etc.), rather than the number of instructions.
The name of the parameter `-fxray-instruction-threshold=N`, as well as XRay documentation at http://llvm.org/docs/XRay.html , suggests that instructions should be counted, rather than the number of basic blocks.
I see two options: 1. Count the number of MachineInstr`s in MachineFunction : this gives better estimate for the number of assembly instructions on the target. So a user can check in disassembly that the threshold works more or less correctly. 2. Count the number of Instruction`s in a Function : AFAIK, this gives correct number of IR instructions, which the user can check in IR listing. However, this number may be far (several times for small functions) from the number of assembly instructions finally emitted.
Option 1 is implemented in this patch because I think that having the closer estimate for the number of assembly instructions emitted is more important than to have a clear definition of the metric.
Reviewers: dberris, rengolin
Reviewed By: dberris
Subscribers: llvm-commits, iid_iunknown
Differential Revision: https://reviews.llvm.org/D34027
llvm-svn: 305072
show more ...
|
#
fb69e66c |
| 06-Jun-2017 |
Eugene Zelenko <eugene.zelenko@gmail.com> |
[CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).
llvm-svn: 304839
|
#
6bda14b3 |
| 06-Jun-2017 |
Chandler Carruth <chandlerc@gmail.com> |
Sort the remaining #include lines in include/... and lib/....
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
Sort the remaining #include lines in include/... and lib/....
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
show more ...
|
Revision tags: llvmorg-4.0.1-rc2 |
|
#
22f2bcf4 |
| 04-May-2017 |
Dean Michael Berris <dberris@google.com> |
[XRay] Detect loops in functions being lowered
Summary: This is an implementation of the loop detection logic that XRay needs to determine whether a function might take time at runtime. Without this
[XRay] Detect loops in functions being lowered
Summary: This is an implementation of the loop detection logic that XRay needs to determine whether a function might take time at runtime. Without this heuristic, XRay will tend to not instrument short functions that have loops that might have runtime dependent on inputs or external values.
While this implementation doesn't do any further analysis than just figuring out whether there is a loop in the MachineFunction being code-gen'ed, we're paving the way for being able to perform more sophisticated analysis of the function in the future (for example to determine whether the trip count for the loop might be constant, and make a decision on that instead). This enables us to cover more functions with the default heuristics, and potentially identify ones that have variable runtime latency just by looking for the presence of loops.
Reviewers: chandlerc, rnk, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32274
llvm-svn: 302103
show more ...
|
Revision tags: llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3 |
|
#
ec657929 |
| 15-Feb-2017 |
Sagar Thakur <sagar.thakur@imgtec.com> |
[LLVM][XRAY][MIPS] Support xray on mips/mipsel/mips64/mips64el
Summary: Adds support for xray instrumentation on mips for both 32-bit and 64-bit.
Reviewed by sdardis, dberris Differential: D27697
[LLVM][XRAY][MIPS] Support xray on mips/mipsel/mips64/mips64el
Summary: Adds support for xray instrumentation on mips for both 32-bit and 64-bit.
Reviewed by sdardis, dberris Differential: D27697
llvm-svn: 295164
show more ...
|
#
918ed871 |
| 10-Feb-2017 |
Tim Shen <timshen91@gmail.com> |
[XRay] Implement powerpc64le xray.
Summary: powerpc64 big-endian is not supported, but I believe that most logic can be shared, except for xray_powerpc64.cc.
Also add a function InvalidateInstructi
[XRay] Implement powerpc64le xray.
Summary: powerpc64 big-endian is not supported, but I believe that most logic can be shared, except for xray_powerpc64.cc.
Also add a function InvalidateInstructionCache to xray_util.h, which is copied from llvm/Support/Memory.cpp. I'm not sure if I need to add a unittest, and I don't know how.
Reviewers: dberris, echristo, iteratee, kbarton, hfinkel
Subscribers: mehdi_amini, nemanjai, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29742
llvm-svn: 294781
show more ...
|
Revision tags: llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1 |
|
#
116bbab4 |
| 13-Jan-2017 |
Diana Picus <diana.picus@linaro.org> |
[CodeGen] Rename MachineInstrBuilder::addOperand. NFC
Rename from addOperand to just add, to match the other method that has been added to MachineInstrBuilder for adding more than just 1 operand.
S
[CodeGen] Rename MachineInstrBuilder::addOperand. NFC
Rename from addOperand to just add, to match the other method that has been added to MachineInstrBuilder for adding more than just 1 operand.
See https://reviews.llvm.org/D28057 for the whole discussion.
Differential Revision: https://reviews.llvm.org/D28556
llvm-svn: 291891
show more ...
|
#
03b8be57 |
| 19-Dec-2016 |
Dean Michael Berris <dberris@google.com> |
[XRay] Fix assertion failure on empty machine basic blocks (PR 31424)
The original version of the code in XRayInstrumentation.cpp assumed that functions may not have empty machine basic blocks (or t
[XRay] Fix assertion failure on empty machine basic blocks (PR 31424)
The original version of the code in XRayInstrumentation.cpp assumed that functions may not have empty machine basic blocks (or that the first one couldn't be). This change addresses that by special-casing that specific situation.
We provide two .mir test-cases to make sure we're handling this appropriately.
Fixes llvm.org/PR31424.
Reviewers: chandlerc
Subscribers: varno, llvm-commits
Differential Revision: https://reviews.llvm.org/D27913
llvm-svn: 290091
show more ...
|
Revision tags: llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
#
a331133e |
| 24-Nov-2016 |
Serge Rogatch <srogatch@accesssoftek.com> |
Test commit access.
llvm-svn: 287898
|
#
3234d3a4 |
| 17-Nov-2016 |
Dean Michael Berris <dberris@google.com> |
[XRay] Support AArch64 in LLVM
This patch adds XRay support in LLVM for AArch64 targets. This patch is one of a series:
Clang: https://reviews.llvm.org/D26415 compiler-rt: https://reviews.llvm.org/
[XRay] Support AArch64 in LLVM
This patch adds XRay support in LLVM for AArch64 targets. This patch is one of a series:
Clang: https://reviews.llvm.org/D26415 compiler-rt: https://reviews.llvm.org/D26413
Author: rSerge
Reviewers: rengolin, dberris
Subscribers: amehsan, aemerson, llvm-commits, iid_iunknown
Differential Revision: https://reviews.llvm.org/D26412
llvm-svn: 287209
show more ...
|
#
156f6caf |
| 18-Oct-2016 |
Dean Michael Berris <dberris@google.com> |
[XRay] Support for for tail calls for ARM no-Thumb
This patch adds simplified support for tail calls on ARM with XRay instrumentation.
Known issue: compiled with generic flags: `-O3 -g -fxray-instr
[XRay] Support for for tail calls for ARM no-Thumb
This patch adds simplified support for tail calls on ARM with XRay instrumentation.
Known issue: compiled with generic flags: `-O3 -g -fxray-instrument -Wall -std=c++14 -ffunction-sections -fdata-sections` (this list doesn't include my specific flags like --target=armv7-linux-gnueabihf etc.), the following program
#include <cstdio> #include <cassert> #include <xray/xray_interface.h>
[[clang::xray_always_instrument]] void __attribute__ ((noinline)) fC() { std::printf("In fC()\n"); }
[[clang::xray_always_instrument]] void __attribute__ ((noinline)) fB() { std::printf("In fB()\n"); fC(); }
[[clang::xray_always_instrument]] void __attribute__ ((noinline)) fA() { std::printf("In fA()\n"); fB(); }
// Avoid infinite recursion in case the logging function is instrumented (so calls logging // function again). [[clang::xray_never_instrument]] void simplyPrint(int32_t functionId, XRayEntryType xret) { printf("XRay: functionId=%d type=%d.\n", int(functionId), int(xret)); }
int main(int argc, char* argv[]) { __xray_set_handler(simplyPrint);
printf("Patching...\n"); __xray_patch(); fA();
printf("Unpatching...\n"); __xray_unpatch(); fA();
return 0; }
gives the following output:
Patching... XRay: functionId=3 type=0. In fA() XRay: functionId=3 type=1. XRay: functionId=2 type=0. In fB() XRay: functionId=2 type=1. XRay: functionId=1 type=0. XRay: functionId=1 type=1. In fC() Unpatching... In fA() In fB() In fC()
So for function fC() the exit sled seems to be called too much before function exit: before printing In fC().
Debugging shows that the above happens because printf from fC is also called as a tail call. So first the exit sled of fC is executed, and only then printf is jumped into. So it seems we can't do anything about this with the current approach (i.e. within the simplification described in https://reviews.llvm.org/D23988 ).
Differential Revision: https://reviews.llvm.org/D25030
llvm-svn: 284456
show more ...
|
#
46401544 |
| 19-Sep-2016 |
Dean Michael Berris <dberris@google.com> |
[XRay] ARM 32-bit no-Thumb support in LLVM
This is a port of XRay to ARM 32-bit, without Thumb support yet. The XRay instrumentation support is moving up to AsmPrinter. This is one of 3 commits to d
[XRay] ARM 32-bit no-Thumb support in LLVM
This is a port of XRay to ARM 32-bit, without Thumb support yet. The XRay instrumentation support is moving up to AsmPrinter. This is one of 3 commits to different repositories of XRay ARM port. The other 2 are:
https://reviews.llvm.org/D23932 (Clang test) https://reviews.llvm.org/D23933 (compiler-rt)
Differential Revision: https://reviews.llvm.org/D23931
llvm-svn: 281878
show more ...
|
#
049f3871 |
| 08-Sep-2016 |
Renato Golin <renato.golin@linaro.org> |
Revert "[XRay] ARM 32-bit no-Thumb support in LLVM"
And associated commits, as they broke the Thumb bots.
This reverts commit r280935. This reverts commit r280891. This reverts commit r280888.
llv
Revert "[XRay] ARM 32-bit no-Thumb support in LLVM"
And associated commits, as they broke the Thumb bots.
This reverts commit r280935. This reverts commit r280891. This reverts commit r280888.
llvm-svn: 280967
show more ...
|
#
cf3801ee |
| 08-Sep-2016 |
Dean Michael Berris <dberris@google.com> |
[XRay] Remove unused variable
llvm-svn: 280891
|