| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 203090
|
| |
|
|
| |
llvm-svn: 203089
|
| |
|
|
|
|
|
|
|
|
|
| |
hold a strong pointer to that extended backtrace thread in the Process
just like we do for asking a thread's extended backtrace.
Also, give extended backtrace threads an invalid ThreadIndexID number.
We'll still give them valid thread_id's. Clients who want to know the
original thread's IndexID can call GetExtendedBacktraceOriginatingIndexID().
<rdar://problem/16126034>
llvm-svn: 203088
|
| |
|
|
| |
llvm-svn: 203087
|
| |
|
|
| |
llvm-svn: 203086
|
| |
|
|
| |
llvm-svn: 203085
|
| |
|
|
| |
llvm-svn: 203084
|
| |
|
|
|
|
|
|
|
|
| |
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
llvm-svn: 203083
|
| |
|
|
|
|
|
|
|
|
| |
DW_AT_GNU_pubnames of DW_FORM_flag(_present) rather than sec_offsets to the pubnames/types sections
This is consistent with GDB ToT and reduces the number of relocations in
(type and compile) units, substantially reducing relocations and debug
size in fission + type units builds.
llvm-svn: 203082
|
| |
|
|
| |
llvm-svn: 203081
|
| |
|
|
| |
llvm-svn: 203080
|
| |
|
|
|
|
| |
inconsistent, making this hard to see.
llvm-svn: 203079
|
| |
|
|
| |
llvm-svn: 203078
|
| |
|
|
| |
llvm-svn: 203077
|
| |
|
|
| |
llvm-svn: 203076
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In addition, for all functions, use the name from the llvm::Function to
identify the function in the profile data. Compute that "function name",
including the file name for local functions, once when assigning the PGO
counters and store it in the CodeGenPGO class.
Move the code to add InlineHint and Cold attributes out of StartFunction(),
because the "function name" string isn't available at that point.
llvm-svn: 203075
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For C++ functions, we will continue to use the mangled name to identify
functions in the PGO profile data, but this name is confusing for things like
Objective-C methods. For functions with local linkage, we're also going to
include the file name to help distinguish those functions, so this changes to
use more generic variable names.
No functional changes.
llvm-svn: 203074
|
| |
|
|
|
|
|
|
|
|
|
| |
Move the PGO.assignRegionCounters() call out of StartFunction, because that
function is called from many places where it does not make sense to do PGO
instrumentation (e.g., compiler-generated helper functions). Change several
functions to take a StringRef argument for the unique name associated with
a function, so that the name can be set differently for things like Objective-C
methods and block literals.
llvm-svn: 203073
|
| |
|
|
|
|
|
|
| |
I hit this while debugging another issue where my sources were in an
inconsistent state, so I don't have a testcase. Regardless, this check is
simpler and more direct than checking if the option is enabled.
llvm-svn: 203072
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
selfhost.
The 'Core.h' C-API header is part of the IR LLVM library. (One might
even argue it should be called IR.h, but that's a separate point.) We
can't include it into a Support header without violating the layering,
and in a way that breaks modules. MemoryBuffer's opaque C type was being
defined in the Core.h C-API header despite being in the Support library,
and thus we ended up with this weird issue.
It turns out that there were other constructs from the Support library
in the Core.h header. This patch lifts all of them into Support.h and
then includes that into Core.h.
The only possible fallout is if someone was including Support.h and
relying on Core.h to be visible for their own uses. Considering the
narrow interface actually provided by the C-API for the Support library,
this seems a very, very unlikely mistake.
llvm-svn: 203071
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, define explicit specializations for the basic types listed in
the SGI documentation. This solves two problems:
1) Helps avoid silent ODR violations caused by the absence of a
user-supplied __gnu_cxx::hash specialization in cases where a std::hash
specialization exists (e.g. for std::string).
2) __gnu_cxx::hash semantics are slightly different to those of
std::hash (for example, the former may dereference a pointer argument)
so it is inappropriate for __gnu_cxx::hash to receive std::hash
specializations by default.
Differential Revision: http://llvm-reviews.chandlerc.com/D2747
llvm-svn: 203070
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
implementation already lived.
After this commit, the only IR-library headers in include/llvm/* are
ones related to the legacy pass infrastructure that I'm planning to
leave there until the new one is farther along.
The only other headers at the top level are linking and initialization
aids that aren't really libraries but just headers.
llvm-svn: 203069
|
| |
|
|
|
|
| |
crashes when lldb follows through exec's...
llvm-svn: 203068
|
| |
|
|
|
|
| |
subdirectory in LLVM r203065.
llvm-svn: 203067
|
| |
|
|
| |
llvm-svn: 203066
|
| |
|
|
|
|
| |
consistent with every other sub-library header in LLVM.
llvm-svn: 203065
|
| |
|
|
|
|
| |
obviously coupled to the IR.
llvm-svn: 203064
|
| |
|
|
|
|
|
|
| |
submodule macro overriding within the same top-level module (necessary for the
testcase to be remotely reasonable). Incidentally reduces the number of libc++
testsuite regressions with modules enabled from 7 to 6.
llvm-svn: 203063
|
| |
|
|
| |
llvm-svn: 203062
|
| |
|
|
| |
llvm-svn: 203061
|
| |
|
|
|
|
|
|
| |
make it true.
It ought to be possible to make this truly random access if anyone cares enough.
llvm-svn: 203060
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the remaining GlobalVariables using "\01L" and
"\01l" prefixes to use private linkage. What is strange about them is
that they currently use WeakAnyLinkage. There is no comment stating
why and that is really odd since the symbols are completely hidden, so
it doesn't make sense for them to be weak.
Clang revisions like r63329, r63408, r63770, r65761 set the linkage to
weak, but don't say why. I suspect they were just copying llvm-gcc.
In llvm-gcc I found r58599 and r56322 that set DECL_WEAK, but they
were just syncing from the apple gcc. I am not exactly sure what that
means, since the last commit to
svn://gcc.gnu.org/svn/gcc/branches/apple was in 2006, 2 years earlier.
In summary, I have no idea why weak linkage was being used :-(
To quote John McCall, "Let’s try without it and see" :-)
llvm-svn: 203059
|
| |
|
|
|
|
| |
Chandler in review.
llvm-svn: 203058
|
| |
|
|
|
|
| |
emitting pub sections for compile units
llvm-svn: 203057
|
| |
|
|
| |
llvm-svn: 203056
|
| |
|
|
| |
llvm-svn: 203055
|
| |
|
|
|
|
|
|
|
| |
The global base register cannot be r0 because it might end up as the first
argument to addi or addis. Fixes PR18316.
I don't have a small stable test case.
llvm-svn: 203054
|
| |
|
|
|
|
|
| |
The iterator is a little complex because we don't want to expose the implementation
details (TrackingVH) of the operand vector to clients.
llvm-svn: 203053
|
| |
|
|
| |
llvm-svn: 203052
|
| |
|
|
|
|
|
|
|
|
| |
condition.
Sometimes do..while() is used to create a scope that can be left early.
In such cases, the unreachable 'while()' test is not usually interesting
unless it actually does something that is observable.
llvm-svn: 203051
|
| |
|
|
|
|
|
| |
a white background is difficult to read. Also include a chart showing which
colors are used by which elements in the AST dump.
llvm-svn: 203050
|
| |
|
|
|
|
| |
in LLVM r203046.
llvm-svn: 203049
|
| |
|
|
|
|
| |
in LLVM r203046.
llvm-svn: 203047
|
| |
|
|
|
|
| |
already lives.
llvm-svn: 203046
|
| |
|
|
|
|
|
| |
Like on other targets, we need to zero_extend/truncate i1 args before copying
them to GPRs.
llvm-svn: 203045
|
| |
|
|
|
|
|
|
| |
pointed to by the attribute, rather than the form as a first
step to determining how to hash the values. No functional change
intended.
llvm-svn: 203044
|
| |
|
|
|
|
|
| |
the property assignment is an lvalue for an incomplete type.
// rdar://15118128. Reviewed offline by John McCall.
llvm-svn: 203043
|
| |
|
|
|
|
|
| |
process (I don't believe it's possible to write a testcase for the bug with
a non-checking STL implementation).
llvm-svn: 203042
|
| |
|
|
|
|
|
|
| |
When copying an i1 value into a GPR for a vaarg call, we need to explicitly
zero-extend the i1 value (otherwise an invalid CRBIT -> GPR copy will be
generated).
llvm-svn: 203041
|
| |
|
|
|
|
| |
in LLVM r203038.
llvm-svn: 203039
|