Summary:
- Modified code that enables writing new user-defined commands
and use them through LLDB CLI. Modifications are:
-- Define the 'syntax' for each user-defined command
--- Added an argument in SBCommandInterpreter::AddCommand()
and SBCommand::AddCommand() API
--- Allow passing syntax for each user-defined command
--- Earlier, only 'help' could be defined and passed for commands
-- Passed 'number of arguments' entered on CLI for user-defined commands
--- Added an argument (number of options) in SBCommandPluginInterface::DoExecute()
API to know the number of arguments passed for commands
-- In CommandPluginInterfaceImplementation class:
--- Make the data member m_backend a shared_ptr
--- Avoids memory leaks of dynamically allocated SBCommandPluginInterface instances
created in lldb::PluginInitialize() API
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, granata.enrico, clayborg
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D22863
llvm-svn: 277125
This addresses some comments from D21612, which contains the following changes:
- Update __xray_patch() and __xray_unpatch() API documentation to not imply asynchrony.
- Introduce a scope cleanup mechanism to make sure we can roll-back changes to the XRayPatching global atomic.
- Introduce a few more comments for potential extension points for other platforms (for the implementation details of patching and un-patching).
Reviewers: eugenis, rnk, kcc, echristo, majnemer
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D22911
llvm-svn: 277124
that it finds on the local computer in "well known" locations
when we start up the darwin-kernel platform. It did not
distinguish between kexts/kernels with dSYMs from others -
when it needed a kernel/kext with a given UUID, it would grab
the first one it finds.
This change separates these into two vectors -- a collection
of kexts and kernels with dSYMs next t othem, and a collection
of kexts and kernels without dSYMs. When we have a bundle ID
and uuid to search for, we first try the collections with
dSYMs, and if that fails, then we try the collections that
did not have dSYMs next to them.
Often times we'll have a situation where a kext will be
installed in multiple locations on a system, but only one
of them will have a dSYM next to it, where the dev just copied
it to a local directory. This fixes that problem, giving
precedence to those binaries with debug information.
llvm-svn: 277123
Summary:
When trying to parse the -break-insert arguments as a named location, the string parsing was not configured to allow directory paths. This patch adds a constructor to allow the parsing of string as directory path along with the other parameters.
This fixes https://llvm.org/bugs/show_bug.cgi?id=28709
Patch from malaperle@gmail.com
Reviewers: clayborg, ki.stfu
Subscribers: lldb-commits, ki.stfu
Differential Revision: https://reviews.llvm.org/D22902
llvm-svn: 277117
Previously, Ignore flag is set if we don't want to assign
a value to symbols. It happens if a symbol assingment is in
PROVIDE() and there's already a symbol with the same name.
The previous code had a subtle but that we assume that the
existing symbol is an absolute symbol even if it is not.
This patch fixes the issue by always overwriting an absolute
symbol.
llvm-svn: 277115
Some instructions may have their uses replaced with a symbolic constant.
However, the instruction may still have side effects which percludes it
from being removed from the function. EarlyCSE treated such an
instruction as if it were removed, resulting in PR28763.
llvm-svn: 277114
According to the specification, CIE code alignment factor is an
arbitrary unsigned LEB128 encoded value.
Differential revision: https://reviews.llvm.org/D22954
llvm-svn: 277105
An undef vector element can be treated as if it had any value. Folding
such a vector element to 0 in a bitcast can open up further folding
opportunities.
llvm-svn: 277104
ConstantExpr::getWithOperands does much of the hard work that
ConstantFoldInstOperandsImpl tries to do but more completely.
This lets us fold ExtractValue/InsertValue expressions.
llvm-svn: 277100
A ConstantVector can have ConstantExpr operands and vice versa.
However, the folder had no ability to fold ConstantVectors which, in
some cases, was an optimization barrier.
Instead, rephrase the folder in terms of Constants instead of
ConstantExprs and teach callers how to deal with failure.
llvm-svn: 277099
I'm not convinced the patterns for the rm_Int was correct anyway. It had a tied source that should't exist for the unmasked version. The load form of MOVSS always zeros the most significant bits. I've left the patterns off the masked load instructions as I'm not sure what the correct pattern should be and we don't have any tests currently. Nor do we implement masked scalar load intrinsics in clang currently.
llvm-svn: 277098
This patch fixes an assertion that fires when we try to add non-pointer
Values to the CFLGraph. Centralizing the check for whether something
is/isn't a pointer type isn't completely trivial (and, in some cases,
would end up being entirely redundant), but it may be beneficial to do
so if this trips us up more in the future.
Patch by Jia Chen.
Differential Revision: https://reviews.llvm.org/D22947
llvm-svn: 277096
Summary:
copypasta doc of ImportedFunctionsInliningStatistics class
\brief Calculate and dump ThinLTO specific inliner stats.
The main statistics are:
(1) Number of inlined imported functions,
(2) Number of imported functions inlined into importing module (indirect),
(3) Number of non imported functions inlined into importing module
(indirect).
The difference between first and the second is that first stat counts
all performed inlines on imported functions, but the second one only the
functions that have been eventually inlined to a function in the importing
module (by a chain of inlines). Because llvm uses bottom-up inliner, it is
possible to e.g. import function `A`, `B` and then inline `B` to `A`,
and after this `A` might be too big to be inlined into some other function
that calls it. It calculates this statistic by building graph, where
the nodes are functions, and edges are performed inlines and then by marking
the edges starting from not imported function.
If `Verbose` is set to true, then it also dumps statistics
per each inlined function, sorted by the greatest inlines count like
- number of performed inlines
- number of performed inlines to importing module
Reviewers: eraman, tejohnson, mehdi_amini
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D22491
llvm-svn: 277089
cache from ObjectFileMachO (very wrong place) to the DynamicLoader
plugins (better place). Not much change to the code itself, although
the old ObjectFileMachO method would try both the new dyld SPI and
reading the dyld_all_image_infos structure. In the new methods,
I've separated those into the appropriate DynamicLoader plugins.
llvm-svn: 277088
This broke some out-of-tree AMDGPU tests that relied on the old behavior
wherein isIntrinsic() would return true for any function that starts
with "llvm.". And in general that change will not play nicely with
out-of-tree backends.
llvm-svn: 277087
Sanitizers set nobuiltin attribute on certain library functions to
avoid a situation where such function is neither instrumented nor
intercepted.
At the moment the list of interesting functions is hardcoded. This
change replaces it with logic based on
TargetLibraryInfo::hasOptimizedCodegen and the presense of readnone
function attribute (sanitizers are generally interested in memory
behavior of library functions).
This is expected to be a no-op change: the new logic matches exactly
the same set of functions.
r276771 (currently reverted) added mempcpy() to the list, breaking
MSan tests. With this change, r276771 can be safely re-landed.
llvm-svn: 277086
Summary:
This change adds a `ni` specifier in the `datalayout` string to denote
pointers in some given address spaces as "non-integral", and adds some
typing rules around these special pointers.
Reviewers: majnemer, chandlerc, atrick, dberlin, eli.friedman, tstellarAMD, arsenm
Subscribers: arsenm, mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D22488
llvm-svn: 277085
Summary:
The motivation is the same as in D22141: In order to add the hotness
attribute to optimization remarks we need BFI to be available in all
passes that emit optimization remarks. BFI depends on BPI so unless we
make this lazy as well we would still compute BPI unconditionally.
The solution is to use the new LazyBPI pass in LazyBFI and only compute
BPI when computation of BFI is requested by the client.
I extended the laziness test using a LoopDistribute test to also cover
BPI.
Reviewers: hfinkel, davidxl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22835
llvm-svn: 277083
Summary:
Test where broken because of missing lifetime markers for temps and
because of aggressive optimization which removed markers in some cases.
PR27453
Reviewers: eugenis, kcc
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D22894
llvm-svn: 277074
Summary:
Asan stack-use-after-scope check should poison alloca even if there is
no access between start and end.
This is possible for code like this:
for (int i = 0; i < 3; i++) {
int x;
p = &x;
}
"Loop Invariant Code Motion" will move "p = &x;" out of the loop, making
start/end range empty.
PR27453
Reviewers: eugenis
Differential Revision: https://reviews.llvm.org/D22842
llvm-svn: 277072
Summary:
Asan stack-use-after-scope check should poison alloca even if there is
no access between start and end.
This is possible for code like this:
for (int i = 0; i < 3; i++) {
int x;
p = &x;
}
"Loop Invariant Code Motion" will move "p = &x;" out of the loop, making
start/end range empty.
PR27453
Reviewers: eugenis
Differential Revision: https://reviews.llvm.org/D22842
llvm-svn: 277068
Greg added in r272276 -- when working with a non-user-process mach-o
core file, force the permissions to readable + executable, else the
unwinder can stop backtracing early if it gets a pc value in a segment
that it thinks is non-executable.
<rdar://problem/27138456>
<rdar://problem/27462904>
llvm-svn: 277065
Summary:
Depends on D22841
We now use a much simpler CFG simplification routine for bugpoint,
because SimplifyCFG is no longer a good match for what bugpoint wants
to do.
At the same time, to make sure we don't lose anything valuable it was doing,
SimplifyCFG is now run as a per-BB reduction pass.
With this and D22841 combined, bugpoint operates both much faster on
the large testcases i have, and reduces them to pretty much minimal
testcases (in one case, bugpoint used to leave about 6000 useless blocks, and
now it leaves 3 ...)
Reviewers: chandlerc, majnemer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22845
llvm-svn: 277063
Abhishek Aggarwal