- Mar 06, 2014
-
-
Ahmed Charles authored
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
-
David Blaikie authored
DebugInfo: Tag units as having been indexed in GNU pubnames by using a 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
-
Alexey Bataev authored
llvm-svn: 203081
-
Ted Kremenek authored
llvm-svn: 203080
-
Ted Kremenek authored
Remove 2 dead 'break' statements. The 'break' usage in this switch is inconsistent, making this hard to see. llvm-svn: 203079
-
Ted Kremenek authored
llvm-svn: 203078
-
Ted Kremenek authored
llvm-svn: 203077
-
Karthik Bhat authored
llvm-svn: 203076
-
Bob Wilson authored
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
-
Bob Wilson authored
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
-
Bob Wilson authored
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
-
Bob Wilson authored
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
-
Chandler Carruth authored
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
-
Peter Collingbourne authored
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
-
Chandler Carruth authored
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
-
Jim Ingham authored
Temporarily disable the JIT loading detector till we figure out why it crashes when lldb follows through exec's... llvm-svn: 203068
-
Chandler Carruth authored
subdirectory in LLVM r203065. llvm-svn: 203067
-
Chandler Carruth authored
llvm-svn: 203066
-
Chandler Carruth authored
consistent with every other sub-library header in LLVM. llvm-svn: 203065
-
Chandler Carruth authored
obviously coupled to the IR. llvm-svn: 203064
-
Richard Smith authored
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
-
Richard Trieu authored
llvm-svn: 203062
-
Richard Trieu authored
llvm-svn: 203061
-
Owen Anderson authored
It ought to be possible to make this truly random access if anyone cares enough. llvm-svn: 203060
-
Rafael Espindola authored
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
-
Owen Anderson authored
Chandler in review. llvm-svn: 203058
-
David Blaikie authored
DebugInfo: Shrink pubnames/pubtypes in the presence of type units by only emitting pub sections for compile units llvm-svn: 203057
-
Raul E. Silvera authored
llvm-svn: 203056
-
Eric Christopher authored
llvm-svn: 203055
-
Hal Finkel authored
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
-
Owen Anderson authored
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
-
Rafael Espindola authored
llvm-svn: 203052
-
Ted Kremenek authored
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
-
Richard Trieu authored
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
-
Chandler Carruth authored
in LLVM r203046. llvm-svn: 203049
-
Chandler Carruth authored
in LLVM r203046. llvm-svn: 203047
-
Chandler Carruth authored
already lives. llvm-svn: 203046
-
Hal Finkel authored
Like on other targets, we need to zero_extend/truncate i1 args before copying them to GPRs. llvm-svn: 203045
-
Eric Christopher authored
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
-
Fariborz Jahanian authored
the property assignment is an lvalue for an incomplete type. // rdar://15118128. Reviewed offline by John McCall. llvm-svn: 203043
-