Replace the crufty build-time configure checks for program paths with
equivalent runtime logic.
This lets users install graphing tools as needed without having to reconfigure
and rebuild LLVM, while eliminating a long chain of inappropriate compile
dependencies that included GUI programs and the windowing system.
Additional features:
* Support the OS X 'open' command to view graphs generated by any of the
Graphviz utilities. This is an alternative to the Graphviz OS X UI which is
no longer available on Mountain Lion.
* Produce informative log output upon failure to indicate which programs can
be installed to view graphs.
Ping me if this doesn't work for your particular environment.
llvm-svn: 210001
Since we cannot yet use variadic templates, add a specialisation for
6-parameters to format. This is motivated by a need for the additional
parameter for formatting information for an unwind decoder for Windows on ARM.
llvm-svn: 209999
Introduce the support structures necessary to deal with the Windows ARM EH data.
These definitions are extremely aggressive about assertions to aid future use
for generation of the entries and subsequent decoding.
The names for the various fields are meant to reflect the names used by the
Visual Studio toolchain to aid communication.
Due to the complexity in reading a few of the values, there are a couple of
additional utility functions to decode the information.
In general, there are two ways to encode the unwinding information:
- packed, which places the data inline into the
_IMAGE_ARM_RUNTIME_FUNCTION_ENTRY structure.
- unpacked, which places the data into auxiliary structures placed into the
.xdata section.
The set of structures allow reading of data in either encoding, with the minor
caveat that epilogue scopes need to be decoded manually by constructing the
structure from the data returned by the RuntimeFunction structure.
These definitions are meant for read-only access at the current point as the
first use of them will be to decode the exception information.
llvm-svn: 209998
Input YAML file might contain multiple object file definitions.
New option `-docnum` allows to specify an ordinal number (starting from 1)
of definition used for an object file generation.
Patch reviewed by Sean Silva.
llvm-svn: 209967
Add a function to combine two 32-bit integers into a 64-bit integer.
There are no calls to this function yet, although a subsequent change
will add some in LLDB.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D3941
llvm-svn: 209777
Previously, DataTypes.h would #define a variety of symbols any time
they weren't already defined. However, some versions of Visual
Studio do provide the appropriate headers, so if those headers are
included after DataTypes.h, it can lead to macro redefinition
warnings.
The fix is to include the appropriate headers if they exist, and
only #define the symbols if the required header does not exist.
Patch by Zachary Turner!
---
The big change here is that we no longer have our own stdint.h
typedefs because now all supported toolchains have stdint.h.
Hooray!
llvm-svn: 209760
Some bit-set fields used in ELF file headers in fact contain two parts.
The first one is a regular bit-field. The second one is an enumeraion.
For example ELF header `e_flags` for MIPS target might contain the
following values:
Bit-set values:
EF_MIPS_NOREORDER = 0x00000001
EF_MIPS_PIC = 0x00000002
EF_MIPS_CPIC = 0x00000004
EF_MIPS_ABI2 = 0x00000020
Enumeration:
EF_MIPS_ARCH_32 = 0x50000000
EF_MIPS_ARCH_64 = 0x60000000
EF_MIPS_ARCH_32R2 = 0x70000000
EF_MIPS_ARCH_64R2 = 0x80000000
For printing bit-sets we use the `yaml::IO::bitSetCase()`. It does not
support bit-set/enumeration combinations and prints too many flags from
an enumeration part. This patch fixes this problem. New method
`yaml::IO::maskedBitSetCase()` handle "enumeration" part of bitset
defined by provided mask.
Patch reviewed by Nick Kledzik and Sean Silva.
llvm-svn: 209504
Windows can't handle paths longer than 260 code points without \\?\. Even
with \\?\ it can't handle path components longer than 255 code points. So
limit graph names to the arbitrary length of 140. Random characters are still
added to the end, so it's ok if graph names collide.
Differential Revision: http://reviews.llvm.org/D3883
llvm-svn: 209483
When pruning superfluous MachO structure definitions, I chose to keep
the most generically useful which is why Support's definitions won over
the ones in MC.
However, the MC copy had some useful comments describing some of the
field values.
Bring these back to the copy in Support. While doing this, fill in some
of the underdocumented definitions as well.
llvm-svn: 209066
OnDiskHashTable::insert() calls the Item constructor via placement new, but
nothing called the destructor. This matters in cases when the Info template
parameter has key_type or data_type typedefs that have a destructor, for
example like IdentifierIndexWriterTrait in clang's GlobalModuleIndex.cpp.
This fixes a 5-year old bug that's been around since the OnDiskHashTable code
was added in r64192. Bug found by LSan!
llvm-svn: 208243
If the source files referenced by a gcno file are missing, gcov
outputs a coverage file where every line is simply /*EOF*/. This also
occurs for lines in the coverage that are past the end of a file that
is found.
This change mimics gcov.
llvm-svn: 208149
In gcov, there's a -n/--no-output option, which disables the writing
of any .gcov files, so that it emits only the summary info on stdout.
This implements the same behaviour in llvm-cov.
llvm-svn: 208148
(OutBufCur + Size) might overflow if Size were large. For example on i686-linux,
OutBufCur: 0xFFFDF27D
OutBufEnd: 0xFFFDF370
Size: 0x0002BF20 (180,000)
It caused flaky error in MC/COFF/section-name-encoding.s.
llvm-svn: 207621
Before this patch, if 'nul' was passed in input to clang, function
getStatus() (in Path.inc) always returned an instance of file_status with
field 'nFileSizeHigh' and 'nFileSizeLow' left uninitialized.
This was causing the triggering of an assertion failure in MemoryBuffer.cpp due
to an invalid FileSize for device 'nul'.
This patch fixes the assertion failure modifying the constructors of class
file_status (in llvm/Support/FileSystem.h) so that every field of the class
gets initialized to zero by default.
A clang test will be submitted on a separate patch.
llvm-svn: 207575
Change `BlockFrequency` to defer to `BranchProbability::scale()` and
`BranchProbability::scaleByInverse()`.
This removes `BlockFrequency::scale()` from its API (and drops the
ability to see the remainder), but the only user was the unit tests. If
some code in the future needs an API that exposes the remainder, we can
add something to `BranchProbability`, but I find that unlikely.
llvm-svn: 207550
domtree. When finding a nearest common dominator, if neither A dominates
B nor B dominates A, we immediately resorted to a tree walk. The tree
walk here is *particularly* expensive because we have to build
a (potentially very large) set for one side's dominators and compare it
with the other side's.
If at any point we have DFS info, we don't need to do any of this. We
can just walk up one side's immediate dominators and return the first
one which dominates the other side. Because of the DFS info, the
dominates queries are trivially constant time.
This reduces the optimizers time in the test case on PR19499 by 70%. It
now optimizes in about 30 seconds for me. And there is still more to be
done for this case.
llvm-svn: 207406
GCOV provides an option to prepend output file names with the source
file name, to disambiguate between covered data that's included from
multiple sources. Add a flag to llvm-cov that does the same.
llvm-svn: 207035
For now it contains a single flag, SanitizeAddress, which enables
AddressSanitizer instrumentation of inline assembly.
Patch by Yuri Gorshenin.
llvm-svn: 206971
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.
This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:
- Header files that need to provide a DEBUG_TYPE for some inline code
can do so by defining the macro before their inline code and undef-ing
it afterward so the macro does not escape.
- We no longer have rampant ODR violations due to including headers with
different DEBUG_TYPE definitions. This may be mostly an academic
violation today, but with modules these types of violations are easy
to check for and potentially very relevant.
Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.
The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.
llvm-svn: 206822
This changes the on-disk hash to get the type to use for offsets from
the Info type, so that clients can be more flexible with the size of
table they support.
llvm-svn: 206643
This changes the on-disk hash to get the size of a hash value from the
Info type, so that clients can be more flexible with the types of hash
they use.
llvm-svn: 206642
