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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209777 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209760 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209504 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209483 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209066 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208243 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208149 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208148 91177308-0d34-0410-b5e6-96231b3b80d8
(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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207621 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207575 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207550 91177308-0d34-0410-b5e6-96231b3b80d8
Add API to `BranchProbability` for scaling big integers. Next job is to
rip the logic out of `BlockMass` and `BlockFrequency`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207544 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207406 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207035 91177308-0d34-0410-b5e6-96231b3b80d8
For now it contains a single flag, SanitizeAddress, which enables
AddressSanitizer instrumentation of inline assembly.
Patch by Yuri Gorshenin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206971 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206822 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206643 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206642 91177308-0d34-0410-b5e6-96231b3b80d8
implementation of the SpecificBumpPtrAllocator -- we have to actually
move the subobject. =] Noticed when using this code more directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206582 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces clang's Basic/OnDiskHashTable.h into llvm as
Support/OnDiskHashTable.h. I've taken the opportunity to add doxygen
comments and run the file through clang-format, but other than the
namespace changing from clang:: to llvm:: the API is identical.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206438 91177308-0d34-0410-b5e6-96231b3b80d8
This is so that EF_MIPS_NAN2008 is set if we are using IEEE 754-2008
NaN encoding (-mnan=2008). This patch also adds support for parsing
'.nan legacy' and '.nan 2008' assembly directives. The handling of
these directives should match GAS' behaviour i.e., the last directive
in use sets the ELF header bit (EF_MIPS_NAN2008).
Differential Revision: http://reviews.llvm.org/D3346
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206396 91177308-0d34-0410-b5e6-96231b3b80d8
