We need to mark the appropriate bits in ThrowInfo and HandlerType so
that the personality routine can correctly handle qualification
conversions.
llvm-svn: 275154
is passed a ModuleSpec with a UUID, it won't accept a file it finds
with a matching FileSpec & ArchSpec, but with a different UUID.
<rdar://problem/27258864>
llvm-svn: 275151
Avoid implicit conversions from MachineInstrBundleIterator to
MachineInstr*, mainly by preferring MachineInstr& over MachineInstr* and
using range-based for loops.
llvm-svn: 275149
Summary:
It's useful to have some visibility about which call sites are devirtualized,
especially for debug purposes. Another use case is a regression test on the
application side (like, Chromium).
Reviewers: pcc
Differential Revision: http://reviews.llvm.org/D22252
llvm-svn: 275145
Avoid implicit iterator conversions from MachineInstrBundleIterator to
MachineInstr* in the Hexagon backend, mostly by preferring MachineInstr&
over MachineInstr* and switching to range-based for loops.
There's a long tail of API cleanup here, but I'm planning to leave the
rest to the Hexagon maintainers. HexagonInstrInfo defines many of its
own predicates, and most of them still take MachineInstr*. Some of
those actually check for nullptr, so I didn't feel comfortable changing
them to MachineInstr& en masse.
llvm-svn: 275142
Avoid implicit conversions from MachineInstrBundleIterator to
MachineInstr* in the Mips backend, mainly by preferring MachineInstr&
over MachineInstr* when a pointer isn't nullable and using range-based
for loops.
llvm-svn: 275141
Summary:
Some thread plans have public contructors, some others have protected
constructors with friend classes. Not sure how these were determined,
but this thread plan is going to be required to implement trampoline
step-through on Windows.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22230
llvm-svn: 275139
Avoid implicit conversions from MachineInstrBundleIterator to
MachineInstr* in the SystemZ backend, mainly by preferring MachineInstr&
over MachineInstr* and using range-based for loops.
llvm-svn: 275137
Summary:
This is already done when building for linux with the CMake build
system. This functionality disappeared recently when some of the build
scripts used by the xcode build system changed.
Reviewers: tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22233
llvm-svn: 275134
The linker supports a feature to force load an object from a static
archive if it defines an Objective-C category.
This API supports this feature by looking at every section in the
module to find if a category is defined in the module.
llvm-svn: 275125
Summary:
This is a cleanup and refactoring of the interception code on windows
Enhancement:
* Adding the support for 64-bits code
* Adding several hooking technique:
* Detour
* JumpRedirect
* HotPatch
* Trampoline
* Adding a trampoline memory pool (64-bits) and release the allocated memory in unittests
Cleanup:
* Adding unittests for 64-bits hooking techniques
* Enhancing the RoundUpInstruction by sharing common decoder
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: http://reviews.llvm.org/D22111
llvm-svn: 275123
This patch simplifies the graph builder by encoding nodes as {Value,
Dereference Level} pairs. This lets us kill edge types, and allows us to
get rid of hacks in StratifiedSets (like addAttrsBelow/...). This
simplification also allows us to remove InstantiatedRelations and
InstantiatedAttrs.
Patch by Jia Chen.
Differential Revision: http://reviews.llvm.org/D22080
llvm-svn: 275122
Do not assign source regions located within system headers file ID's,
and do not construct counter mapping regions out of them.
This makes coverage reports less cluttered and less mysterious. E.g
using the "assert" macro doesn't cause assert.h to appear in reports,
and it no longer shows the "assertion failed" branch as an uncovered
region.
It also makes coverage mapping sections a bit smaller (e.g a 1%
reduction in a stage2 build of bin/llvm-as).
llvm-svn: 275121
The issue was we have two global variables: one that contains a DebuggerList pointer and one that contains a std::mutex pointer. These get initialized in Debugger::Initialize(), and everywhere that uses these does:
if (g_debugger_list_ptr && g_debugger_list_mutex_ptr)
{
std::lock_guard<std::recursive_mutex> guard(*g_debugger_list_mutex_ptr);
// do work while mutex is locked
}
Debugger::Terminate() was deleting and nulling out g_debugger_list_ptr which meant we had a race condition where someone might do the if statement and it evaluates to true, then another thread calls Debugger::Terminate() and deletes and nulls out g_debugger_list_ptr while holding the mutex, and another thread then locks the mutex and tries to use g_debugger_list_ptr. The fix is to just not delete and null out the g_debugger_list_ptr variable.
llvm-svn: 275119
Summary:
Aiming to correct the ordering of loads/stores. This patch changes the
insert point for loads to the position of the first load.
It updates the ordering method for loads to insert before, rather than after.
Before this patch the following sequence:
"load a[1], store a[1], store a[0], load a[2]"
Would incorrectly vectorize to "store a[0,1], load a[1,2]".
The correctness check was assuming the insertion point for loads is at
the position of the first load, when in practice it was at the last
load. An alternative fix would have been to invert the correctness check.
The current fix changes insert position but also requires reordering of
instructions before the vectorized load.
Updated testcases to reflect the changes.
Reviewers: tstellarAMD, llvm-commits, jlebar, arsenm
Subscribers: mzolotukhin
Differential Revision: http://reviews.llvm.org/D22071
llvm-svn: 275117
Immediate branch targets aren't commonly used, but if they are we should make
sure they can actually be encoded. This means they must be divisible by 2 when
targeting Thumb mode, and by 4 when targeting ARM mode.
Also do a little naming cleanup while I was changing everything around anyway.
llvm-svn: 275116
Summary:
Nested if statements can generate empty BBs whose terminator branches
unconditionally to its successor. These branches are not eliminated
to help generate better line number information in some cases, but there
is no reason to keep the empty blocks that result from nested ifs.
Reviewers: mehdi_amini, dblaikie, echristo
Subscribers: mehdi_amini, cfe-commits
Differential review: http://reviews.llvm.org/D11360
llvm-svn: 275115
This cleans up a previous optimization attempt in hash, and results in
additional performance improvements over that previous attempt. Additionally
this new optimization does not hinder the power of 2 bucket count optimization.
llvm-svn: 275114
Summary:
Setting MIMG to 0 has a bunch of unexpected side effects, including that
isVMEM returns false which leads to incorrect treatment in the hazard
recognizer. The reason I noticed it is that it also leads to incorrect
treatment in VGPR-to-SGPR copies, which is one cause of the referenced bug.
The only reason why MIMG was set to 0 is to signal the special handling of
dmasks, but that can be checked differently.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96877
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, kzhuravl, llvm-commits
Differential Revision: http://reviews.llvm.org/D22210
llvm-svn: 275113
Summary:
This patch is a refactoring of the way cmake 'targets' are grouped.
It won't affect non-UI cmake-generators.
Clang/LLVM are using a structured way to group targets which ease
navigation through Visual Studio UI. The Compiler-RT projects
differ from the way Clang/LLVM are grouping targets.
This patch doesn't contain behavior changes.
Reviewers: kubabrecka, rnk
Subscribers: wang0109, llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21952
llvm-svn: 275111
This will be useful once we start adding the ability to dump type
records and symbol records, since it will allow us to generate
mergeable information instead of information that specifies an
entire file.
llvm-svn: 275109
Summary:
The main bug fix here is using the 32-bit encoding of V_ADD_I32 in
materializeFrameBaseRegister and resolveFrameIndex, so that arbitrary
immediates work.
The second part is that we may now require the SegmentWaveByteOffset
even when there are initially no stack objects and VGPR spilling isn't
enabled, for stack slots that are allocated later. This means that some
bits become effectively dead and can be cleaned up.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96602
Tested-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: http://reviews.llvm.org/D21551
llvm-svn: 275108
Memory will be committed on demand when exception happens while accessing
shadow memeory region.
Patch by: Wei Wang
Differential Revision: http://reviews.llvm.org/D21942
llvm-svn: 275107
Eugene Leviant