| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Previously the code used getActiveBits() to determine the highest set
bit of each APInt first. However doing so requires the same amount of
memory accesses as simply comparing both numbers right away.
Removing all the active bit checks leads to simpler code and is faster
in my benchmark.
Differential Revision: http://reviews.llvm.org/D16620
llvm-svn: 260447
 | 
| | 
| 
| 
|  | 
llvm-svn: 260446
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
We already do this for Objective-C interfaces, but we never handled protocols
because the DWARF didn't represent them.  Nowadays, though, we can import them
from modules, and we have to mark them properly.
<rdar://problem/24193009>
llvm-svn: 260445
 | 
| | 
| 
| 
|  | 
llvm-svn: 260444
 | 
| | 
| 
| 
|  | 
llvm-svn: 260443
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This restores commit r260408, along with a fix for a bot failure.
The bot failure was caused by dereferencing a unique_ptr in the same
call instruction parameter list where it was passed via std::move.
Apparently due to luck this was not exposed when I built the compiler
with clang, only with gcc.
llvm-svn: 260442
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
static_cast of a pointer to object before the start of the object's
lifetime has undefined behavior.
This code triggers CFI warnings.
This change replaces C-style casts with reinterpret_cast, which is
fine per the standard, add applies an attribute to silence CFI (which
barks on reinterpret_cast, too).
llvm-svn: 260441
 | 
| | 
| 
| 
|  | 
llvm-svn: 260440
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
There's nothing preventing callers of LVI from asking for lattice values representing a Constant.  In fact, given that several callers are walking back through PHI nodes and trying to simplify predicates, such queries are actually quite common.  This is mostly harmless today, but we start volatiling assertions if we add new calls to getBlockValue in otherwise reasonable places.
Note that this change is not NFC.  Specifically:
1) The result returned through getValueAt will now be more precise.  In principle, this could trigger any latent infinite optimization loops in callers, but in practice, we're unlikely to see this.
2) The result returned through getBlockValueAt is potentially weakened for non-constants that were previously queried.  With the old code, you had the possibility that a later query might bypass the cache and discover some information the original query did not.  I can't find a scenario which actually causes this to happen, but it was in principle possible.  On the other hand, this may end up reducing compile time when the same value is queried repeatedly.  
llvm-svn: 260439
 | 
| | 
| 
| 
|  | 
llvm-svn: 260438
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
We have a vector of all of the compact unwind entries anyway, and
its live as long as we need it to be.  So instead of copying from that
vector to another, just take references to the range of the original vector
we need for each compact unwind page.
llvm-svn: 260437
 | 
| | 
| 
| 
|  | 
llvm-svn: 260436
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Previously LLVM could not process any debug info we produced, so it
didn't make sense to spend time generating it. Now that it has primitive
support for local variable info, it does make sense to generate normal
debug info.
llvm-svn: 260435
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
file with "-fmodules -gmodules", each SymbolFileDWARF can reference module DWARF info by looking in other DWARF files. Then if you have 1000 .o files that each reference one or more .pcm files in their debug info, a simple Module::FindTypes(...) call can end up searching the same .pcm file over and over and over. Now all internal FindTypes methods in classes (ModuleList, Module, SymbolFile) now take an extra argument:
    llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files
    
Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries. 
This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files. 
<rdar://problem/24581488>
llvm-svn: 260434
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Reviewers: weimingz
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17085
llvm-svn: 260433
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
Refactor common value, scope, and label tracking logic out of DwarfDebug
into a common base class called DebugHandlerBase.
Update an old LLVM IR test case to avoid an assertion in LexicalScopes.
Reviewers: dblaikie, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16931
llvm-svn: 260432
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This time I kept <ext/hash_map> working!
This patch is the first in a series of patches that's meant to better
support unordered_map. unordered_map has a special "value_type" that
differs from pair<const Key, Value>. In order to meet the EmplaceConstructible
and CopyInsertable requirements we need to teach __hash_table about this
special value_type.
This patch creates a "__hash_node_types" traits class that contains
all of the typedefs needed by the unordered containers and it's iterators.
These typedefs include ones for each node type and  node pointer type,
as well as special typedefs for "unordered_map"'s value type.
As a result of this change all of the unordered containers now all support
incomplete types.
As a drive-by fix I changed the difference_type in __hash_table to always
be ptrdiff_t. There is a corresponding change to size_type but it cannot
take affect until an ABI break.
This patch will be followed up shortly with fixes for various unordered_map
bugs and problems.
llvm-svn: 260431
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
New option --elf-output-style=LLVM or GNU
Enables -file-headers in readelf style when elf-output-style=GNU
Differential revision: http://reviews.llvm.org/D14128
llvm-svn: 260430
 | 
| | 
| 
| 
|  | 
llvm-svn: 260429
 | 
| | 
| 
| 
|  | 
llvm-svn: 260428
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
This fixes a crash where subsequent spills would be unable to scavenge
a register. In particular, it fixes a crash in piglit's
spec@glsl-1.50@execution@geometry@max-input-components (the test still
has a shader that fails to compile because of too many SGPR spills, but
at least it doesn't crash any more).
This is a candidate for the release branch.
Reviewers: arsenm, tstellarAMD
Subscribers: qcolombet, arsenm
Differential Revision: http://reviews.llvm.org/D16558
llvm-svn: 260427
 | 
| | 
| 
| 
|  | 
llvm-svn: 260426
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
that's not true in general. Instead, use a preference order to pick the
standard C++ signature 'char*(char*, int)' where possible and fall back to the
C signature 'char*(const char*, int)' only when it's unavailable.
llvm-svn: 260425
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The patch adds lazy relocation support for MIPS and R_MIPS_26 relocation
handing.
R_MIPS_26 relocation might require PLT entry creation. In that case it
is fully supported by the patch. But if the relocation target is a local
symbol we need to use a different expression to calculate the relocation
result. This case is not implemented yet because there is no method to
get know the kind of relocation target in the `relocateOne` routine.
Differential Revision: http://reviews.llvm.org/D16982
llvm-svn: 260424
 | 
| | 
| 
| 
| 
| 
| 
|  | 
This was supposed to have been removed but made it back in
accidentally.
llvm-svn: 260423
 | 
| | 
| 
| 
|  | 
llvm-svn: 260422
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Instead of passing varargs directly on the user stack, allocate a buffer in
the caller's stack frame and pass a pointer to it. This simplifies the C
ABI (e.g. non-C callers of C functions do not need to use C's user stack if
they have their own mechanism) and allows further optimizations in the future
(e.g. fewer functions may need to use the stack).
Differential Revision: http://reviews.llvm.org/D17048
llvm-svn: 260421
 | 
| | 
| 
| 
| 
| 
|  | 
The following batch files allow to launch scan-build from an arbitrary location if path to clang\tools\scan-build-py\bin is added to %PATH%.
llvm-svn: 260420
 | 
| | 
| 
| 
|  | 
llvm-svn: 260419
 | 
| | 
| 
| 
|  | 
llvm-svn: 260418
 | 
| | 
| 
| 
| 
| 
|  | 
covered switch
llvm-svn: 260417
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Very often in LLVM we have APIs that take a bitwidth and a uint64_t that
we pass immediates such as ~0U to. Consider APInt, Constant, and
MachineInstrBuilder::addImm. Fixing all uses of these APIs to manually
extend their arguments to uint64_t doesn't seem worth it.
llvm-svn: 260416
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
fixes.
Differential revision: http://reviews.llvm.org/D17060
llvm-svn: 260414
 | 
| | 
| 
| 
|  | 
llvm-svn: 260413
 | 
| | 
| 
| 
| 
| 
|  | 
This reverts commit r260408. Bot failure that I need to investigate.
llvm-svn: 260412
 | 
| | 
| 
| 
| 
| 
|  | 
off the end of a covered switch
llvm-svn: 260411
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
attributes
Patch by Alexander Riccio
This patch enables `constexpr` on Visual Studio 2015 by adding `||
LLVM_MSC_PREREQ(1900)` to the preprocessor `#if` statement. Since VS2013
doesn't support `constexpr`, that's purposely excluded. The
`LLVM_CONSTEXPR` macro is used in ~25 places.
I also added the MSVC/SAL equivalent of:
  - `__attribute__((__warn_unused_result__))` as an
    `LLVM_ATTRIBUTE_UNUSED_RESULT` definition
  - `__attribute__((returns_nonnull))` as an
    `LLVM_ATTRIBUTE_RETURNS_NONNULL` definition
...in case anybody ever decides to run `/analyze` on LLVM (probably
myself, if anybody)
Reviewers: rnk, aaron.ballman
Differential Revision: http://reviews.llvm.org/D16751
llvm-svn: 260410
 | 
| | 
| 
| 
|  | 
llvm-svn: 260409
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
This patch uses the lower 64-bits of the MD5 hash of a function name as
a GUID in the function index, instead of storing function names. Any
local functions are first given a global name by prepending the original
source file name. This is the same naming scheme and GUID used by PGO in
the indexed profile format.
This change has a couple of benefits. The primary benefit is size
reduction in the combined index file, for example 483.xalancbmk's
combined index file was reduced by around 70%. It should also result in
memory savings for the index file in memory, as the in-memory map is
also indexed by the hash instead of the string.
Second, this enables integration with indirect call promotion, since the
indirect call profile targets are recorded using the same global naming
convention and hash. This will enable the function importer to easily
locate function summaries for indirect call profile targets to enable
their import and subsequent promotion.
The original source file name is recorded in the bitcode in a new
module-level record for use in the ThinLTO backend pipeline.
Reviewers: davidxl, joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D17028
llvm-svn: 260408
 | 
| | 
| 
| 
|  | 
llvm-svn: 260407
 | 
| | 
| 
| 
|  | 
llvm-svn: 260406
 | 
| | 
| 
| 
|  | 
llvm-svn: 260405
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Currently you can't specify node properties like commutativity on
a PatFrag. If you want to create a PatFrag on a commutative node
with a hasOneUse predicate, this enables you to specify that the
PatFrag is also commutable.
llvm-svn: 260404
 | 
| | 
| 
| 
|  | 
llvm-svn: 260403
 | 
| | 
| 
| 
|  | 
llvm-svn: 260402
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: http://reviews.llvm.org/D17038
llvm-svn: 260401
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This patch reads the indirect-call value records in the profile and makes the
annotation in the indirect-call instruction. This is for IR level profile
instrumentation.
Differential Revision: http://reviews.llvm.org/D16935
llvm-svn: 260400
 | 
| | 
| 
| 
|  | 
llvm-svn: 260399
 | 
| | 
| 
| 
| 
| 
| 
|  | 
These weren't actually sharing anything in the common
LowerLOAD.
llvm-svn: 260398
 | 
| | 
| 
| 
| 
| 
|  | 
This reverts commit a58765909660a7195b32e0cc8c7476168b913750.
llvm-svn: 260397
 |