| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 183868
|
|
|
|
| |
llvm-svn: 183866
|
|
|
|
| |
llvm-svn: 183865
|
|
|
|
|
|
|
| |
It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just
those two functions and make Execute and Wait implementations details.
llvm-svn: 183864
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 183842
|
|
|
|
| |
llvm-svn: 183840
|
|
|
|
| |
llvm-svn: 183839
|
|
|
|
| |
llvm-svn: 183838
|
|
|
|
| |
llvm-svn: 183836
|
|
|
|
| |
llvm-svn: 183835
|
|
|
|
| |
llvm-svn: 183833
|
|
|
|
| |
llvm-svn: 183831
|
|
|
|
|
|
|
|
|
| |
`typeinfo for llvm::cl::GenericOptionValue').
Remove an "anchor" method for an abstract class. (This does not
increase the number of vtables.)
llvm-svn: 183830
|
|
|
|
| |
llvm-svn: 183828
|
|
|
|
| |
llvm-svn: 183827
|
|
|
|
| |
llvm-svn: 183826
|
|
|
|
|
|
|
| |
Most clients have already been moved from Path V1 to V2. The ones using V1
now include PathV1.h explicitly.
llvm-svn: 183801
|
|
|
|
|
|
|
|
|
|
|
|
| |
For ARM on linux we use /proc/cpuinfo to detect the host CPU's features.
Linux derives these values without ever looking at the vendor of the
specific CPU implementation. Hence, it adds little value, if we parse
the output of /proc/cpuinfo only for certain vendors.
This patch enables us to derive the correct feature flags e.g. for Qualcomm
CPUs.
llvm-svn: 183790
|
|
|
|
|
|
| |
This is preparation for replacing Path.h with PathV2.h.
llvm-svn: 183782
|
|
|
|
| |
llvm-svn: 183780
|
|
|
|
| |
llvm-svn: 183779
|
|
|
|
| |
llvm-svn: 183778
|
|
|
|
| |
llvm-svn: 183777
|
|
|
|
| |
llvm-svn: 183775
|
|
|
|
| |
llvm-svn: 183773
|
|
|
|
| |
llvm-svn: 183770
|
|
|
|
| |
llvm-svn: 183765
|
|
|
|
| |
llvm-svn: 183764
|
|
|
|
| |
llvm-svn: 183763
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It will be tested in the next commit which moves another user to identify_magic.
Original message:
Fix an out of bounds array access.
We were looking at Magic[5] without checking Length. Since this path would not
return unless Length >= 18 anyway, just move the >= 18 check up.
llvm-svn: 183753
|
|
|
|
| |
llvm-svn: 183752
|
|
|
|
| |
llvm-svn: 183692
|
|
|
|
| |
llvm-svn: 183669
|
|
|
|
|
|
|
| |
We were looking at Magic[5] without checking Length. Since this path would not
return unless Length >= 18 anyway, just move the >= 18 check up.
llvm-svn: 183666
|
|
|
|
|
|
| |
I will change identifyFileType to use a StringRef in the next patch.
llvm-svn: 183664
|
|
|
|
|
|
| |
handle on Windows. Patch thanks to Kim Gräsman!
llvm-svn: 183621
|
|
|
|
|
|
|
|
|
| |
This is needed in clang so one can check if the object needs the
destructor called after its memory was freed. This is useful when
creating many APInt/APFloat objects with placement new, where the
overhead of tracking the pointers for cleanup is significant.
llvm-svn: 183100
|
|
|
|
| |
llvm-svn: 183073
|
|
|
|
| |
llvm-svn: 183072
|
|
|
|
| |
llvm-svn: 183054
|
|
|
|
| |
llvm-svn: 183053
|
|
|
|
| |
llvm-svn: 183052
|
|
|
|
| |
llvm-svn: 183051
|
|
|
|
|
|
|
|
| |
function APFloat::next(bool nextDown).
rdar://13852078
llvm-svn: 182945
|
|
|
|
|
|
|
|
| |
use in APFloat IEEE-754R 2008 nextUp/nextDown function.
rdar://13852078
llvm-svn: 182801
|
|
|
|
|
|
|
| |
Add a stringize method to make dumping a bit easier, and add a testcase
exercising a few different paths.
llvm-svn: 182692
|
|
|
|
| |
llvm-svn: 182680
|
|
|
|
|
|
|
|
|
|
| |
There was exactly one caller using this API right, the others were relying on
specific behavior of the default implementation. Since it's too hard to use it
right just remove it and standardize on the default behavior.
Defines away PR16132.
llvm-svn: 182636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch builds on some existing code to do CFG reconstruction from
a disassembled binary:
- MCModule represents the binary, and has a list of MCAtoms.
- MCAtom represents either disassembled instructions (MCTextAtom), or
contiguous data (MCDataAtom), and covers a specific range of addresses.
- MCBasicBlock and MCFunction form the reconstructed CFG. An MCBB is
backed by an MCTextAtom, and has the usual successors/predecessors.
- MCObjectDisassembler creates a module from an ObjectFile using a
disassembler. It first builds an atom for each section. It can also
construct the CFG, and this splits the text atoms into basic blocks.
MCModule and MCAtom were only sketched out; MCFunction and MCBB were
implemented under the experimental "-cfg" llvm-objdump -macho option.
This cleans them up for further use; llvm-objdump -d -cfg now generates
graphviz files for each function found in the binary.
In the future, MCObjectDisassembler may be the right place to do
"intelligent" disassembly: for example, handling constant islands is just
a matter of splitting the atom, using information that may be available
in the ObjectFile. Also, better initial atom formation than just using
sections is possible using symbols (and things like Mach-O's
function_starts load command).
This brings two minor regressions in llvm-objdump -macho -cfg:
- The printing of a relocation's referenced symbol.
- An annotation on loop BBs, i.e., which are their own successor.
Relocation printing is replaced by the MCSymbolizer; the basic CFG
annotation will be superseded by more related functionality.
llvm-svn: 182628
|
|
|
|
| |
llvm-svn: 182349
|