Introduce DIPrinter which takes care of rendering DILineInfo and
friends. This allows LLVMSymbolizer class to return a structured data
instead of plain std::strings.
llvm-svn: 251989
This is a case where there is inconsistency among ELF linkers:
* The spec says nothing special about empty sections.
* BFD ld removes them.
* Gold handles them like regular sections.
We were outputting them but sometimes ignoring them. This would create
odd looking outputs where a rw section could be in a ro segment for example.
The bfd way of doing things is also strange for the case where a symbol
points to the empty section.
Now we match gold and what seems to be the intention of the spec.
llvm-svn: 251988
Summary:
We now collect all types of dependences including lexically forward
deps not just "interesting" ones.
Reviewers: hfinkel
Subscribers: rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D13256
llvm-svn: 251985
This patch actually introduces a dependency from unittest2 to
six. This should be ok since both packages are in our own
repo, and we assume a sys.path of the top-level script that
can find the third party packages. So unittest2 should be
able to find six.
llvm-svn: 251983
Make printDILineInfo and friends responsible for just rendering the
contents of the structures, demangling should actually be performed
earlier, when we have the information about the originating
SymbolizableModule at hand.
llvm-svn: 251981
Let the editor also clean up whitespace for that file.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13816
llvm-svn: 251979
unittest2 was using print statements in a few places, and also
using the `cmp` function (which is removed in Python 3). Again,
we need to stop using unittest2 and using unittest instead, but
this seems like an easier route for now.
llvm-svn: 251978
XOP has the VPCMOV instruction that performs the common vector bit select operation OR( AND( SRC1, SRC3 ), AND( SRC2, ~SRC3 ) )
This patch adds tablegen pattern matching for this instruction.
Differential Revision: http://reviews.llvm.org/D8841
llvm-svn: 251975
Summary:
When the dependence distance in zero then we have a loop-independent
dependence from the earlier to the later access.
No current client of LAA uses forward dependences so other than
potentially hitting the MaxDependences threshold earlier, this change
shouldn't affect anything right now.
This and the previous patch were tested together for compile-time
regression. None found in LNT/SPEC.
Reviewers: hfinkel
Subscribers: rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D13255
llvm-svn: 251973
Summary:
Before this change, we didn't use to collect forward dependences since
none of the current clients (LV, LDist) required them.
The motivation to also collect forward dependences is a new pass
LoopLoadElimination (LLE) which discovers store-to-load forwarding
opportunities across the loop's backedge. The pass uses both lexically
forward or backward loop-carried dependences to detect these
opportunities.
The new pass also analyzes loop-independent (forward) dependences since
they can conflict with the loop-carried dependences in terms of how the
data flows through memory.
The newly added test only covers loop-carried forward dependences
because loop-independent ones are currently categorized as NoDep. The
next patch will fix this.
The two patches were tested together for compile-time regression. None
found in LNT/SPEC.
Note that with this change LAA provides all dependences rather than just
"interesting" ones. A subsequent NFC patch will remove the now trivial
isInterestingDependence and rename the APIs.
Reviewers: hfinkel
Subscribers: jmolloy, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D13254
llvm-svn: 251972
Old-style syntax: `except Exception, e:`
New-style syntax: `except Exception as e:`
These two statements are identical, except that the former has
been deprecated for may versions, and was removed in Python 3.
This converts everything to use the new syntax (which also works
in Python 2). I had to convert unittest2 as well. What we really
need to do is just delete unittest2, and use unittest instead since
it is a standard module that ships with every Python distribution.
But this is the path of least resistance for now, although at
some point we will really need to do it.
llvm-svn: 251968
This reverts commit r251926. I believe this is causing an LTO
bootstrapping bot failure
(http://lab.llvm.org:8080/green/job/llvm-stage2-cmake-RgLTO_build/3669/).
Haven't been able to repro it yet, but after looking at the metadata I
am pretty sure I know what is going on.
llvm-svn: 251965
This module was originally intended to be imported by top-level
scripts to be able to find the LLDB packages and third party
libraries. Packages themselves shouldn't need to import it,
because by the time it gets into the package, the top-level
script should have already done this. Indeed, it was just
adding the same values to sys.path multiple times, so this
patch is essentially no functional change.
To make sure it doesn't get re-introduced, we also delete the
`use_lldb_suite` module from `lldbsuite/test`, although the
original copy still remains in `lldb/test`
llvm-svn: 251963
To simplify and correct the preloading of a base pointer origin, e.g.,
the base pointer for the current indirect invariant load, we now just
check if there is an invariant access class that involves the base
pointer of the current class.
llvm-svn: 251962
The `commands` module was deprecated in 2.7 and removed in 3.x.
As a workaround, we introduce a new module `seven` in
lldbsuite.support, and write helper functions in there that delegate
to the commands module if it is available, and re-implement their
functionality for cases where it is not available.
llvm-svn: 251959
Introduce the notion of a module file extension, which introduces
additional information into a module file at the time it is built that
can then be queried when the module file is read. Module file
extensions are identified by a block name (which must be unique to the
extension) and can write any bitstream records into their own
extension block within the module file. When a module file is loaded,
any extension blocks are matched up with module file extension
readers, that are per-module-file and are given access to the input
bitstream.
Note that module file extensions can only be introduced by
programmatic clients that have access to the CompilerInvocation. There
is only one such extension at the moment, which is used for testing
the module file extension harness. As a future direction, one could
imagine allowing the plugin mechanism to introduce new module file
extensions.
llvm-svn: 251955
The required compiler-rt changes aren't present yet so attempting to
build with compiler-rt breaks. And since we're trying to deprecate
autotools we actually want to fix this in CMake primarily anyway.
This reverts r251712.
llvm-svn: 251953
Now that the properties created within Objective-C class extensions go
into the extension themselves, we don't need any of the extra
complexity here.
llvm-svn: 251949
We do not need to model read-only statements in the SCoP as they will
not cause any side effects that are visible to the outside anyway.
Removing them should safe us time and might even simplify the ASTs we
generate.
Differential Revision: http://reviews.llvm.org/D14272
llvm-svn: 251948
Matt Arsenault