- Jan 17, 2015
-
-
Chandler Carruth authored
a LoopInfoWrapperPass to wire the object up to the legacy pass manager. This switches all the clients of LoopInfo over and paves the way to port LoopInfo to the new pass manager. No functionality change is intended with this iteration. llvm-svn: 226373
-
Nico Weber authored
llvm-svn: 226372
-
Nico Weber authored
llvm-svn: 226371
-
Nico Weber authored
llvm-svn: 226370
-
Hal Finkel authored
R11's status is the same under both the PPC64 ELF V1 and V2 ABIs: it is reserved for use as an "environment pointer" for compilation models that require such a thing. We don't, we also don't need a second scratch register, and because we support only "local" patchpoint call targets, we might as well let R11 be used for anyregcc patchpoints. llvm-svn: 226369
-
Hal Finkel authored
Setting the maximum read size in FlagHandlerInclude to 2^15 might be a good default, but causes the read to fail on systems with a page size larger than that (ReadFileToBuffer(...) will fail if the maximum allowed size is less than the value returned by GetPageSizeCached()). For example, on my PPC64/Linux system, GetPageSizeCached() returns 2^16. In case the page size is larger, use that instead. llvm-svn: 226368
-
Hans Wennborg authored
llvm-svn: 226367
-
Enrico Granata authored
llvm-svn: 226366
-
Nico Weber authored
Clang currently crashes on class C { C() = default; C() = delete; }; My cunning plan for fixing this was to change the `if (!FnD)` in Parser::ParseCXXInlineMethodDef() to `if (!FnD || FnD->isInvalidDecl)` – but alas, the second constructor decl wasn't marked as invalid. This lets Sema::MergeFunctionDecl() return true on function redeclarations, which leads to them being marked invalid. This also improves error messages when functions are redeclared. llvm-svn: 226365
-
Nico Weber authored
llvm-svn: 226364
-
Nico Weber authored
llvm-svn: 226363
-
Vince Harron authored
This function returns a URI of the resource that the connection is connected to. This is especially important for connections established by accepting a connection from a remote host. Also added implementations for ConnectionMachPort, ConnectionSharedMemory, Also fixed up some documentation in Connection::Write Renamed ConnectionFileDescriptorPosix::SocketListen to ConnectionFileDescriptorPosix::SocketListenAndAccept Fixed a log message in Socket.cpp Differential Review: http://reviews.llvm.org/D7026 llvm-svn: 226362
-
Rafael Espindola authored
Destructors have a special treatment in getFunctionLinkage. Instead of duplicating the logic, check the resulting linkage. llvm-svn: 226361
-
Mehdi Amini authored
Loading 2 2x32-bit float vectors into the bottom half of a 256-bit vector produced suboptimal code in AVX2 mode with certain IR combinations. In particular, the IR optimizer folded 2f32 + 2f32 -> 4f32, 4f32 + 4f32 (undef) -> 8f32 into a 2f32 + 2f32 -> 8f32, which seems more canonical, but then mysteriously generated rather bad code; the movq/movhpd combination didn't match. The problem lay in the BUILD_VECTOR optimization path. The 2f32 inputs would get promoted to 4f32 by the type legalizer, eventually resulting in a BUILD_VECTOR on two 4f32 into an 8f32. The BUILD_VECTOR then, recognizing these were both half the output size, concatted them and then produced a shuffle. However, the resulting concat + shuffle was more complex than it should be; in the case where the upper half of the output is undef, we probably want to generate shuffle + concat instead. This enhancement causes the vector_shuffle combine step to recognize this suboptimal pattern and correct it. I included it there instead of in BUILD_VECTOR in case the same suboptimal pattern occurs for other reasons. This results in the optimizer correctly producing the optimal movq + movhpd sequence for all three variations on this IR, even with AVX2. I've included a test case. Radar link: rdar://problem/19287012 Fix for PR 21943. From: Fiona Glaser <fglaser@apple.com> llvm-svn: 226360
-
Richard Trieu authored
llvm-svn: 226359
-
Lang Hames authored
llvm-svn: 226358
-
Richard Trieu authored
llvm-svn: 226357
-
Richard Trieu authored
llvm-svn: 226356
-
Matthias Braun authored
llvm-svn: 226353
-
Matthias Braun authored
llvm-svn: 226352
-
Matthias Braun authored
- Consistenly put comments above the function declaration, not the definition. To achieve this some duplicate comments got merged and some comment parts describing implementation details got moved into their functions. - Consistently use doxygen comments above functions. - Do not use doxygen comments inside functions. llvm-svn: 226351
-
Matthias Braun authored
llvm-svn: 226350
-
Lang Hames authored
Evidently MSVC doesn't like it. llvm-svn: 226349
-
Jason Molenda authored
ABIMacOSX_i386::CreateFunctionEntryUnwindPlan, ABIMacOSX_i386::CreateDefaultUnwindPlan, ABISysV_x86_64::CreateFunctionEntryUnwindPlan, ABISysV_x86_64::CreateDefaultUnwindPlan llvm-svn: 226347
-
Greg Fitzgerald authored
Differential Revision: http://reviews.llvm.org/D7023 From: Greg Fitzgerald <garious@gmail.com> llvm-svn: 226346
-
Kevin Enderby authored
while I once again try to figure out why only the clang-cmake-armv7-a15-full bot is getting that value wrong. llvm-svn: 226345
-
Philip Reames authored
Be a bit more explicit about the fact that addrspace(1) is not reserved. llvm-svn: 226344
-
Enrico Granata authored
llvm-svn: 226343
-
Philip Reames authored
Nothing interesting here... llvm-svn: 226342
-
Lang Hames authored
RuntimeDyld symbol info previously consisted of just a Section/Offset pair. This patch replaces that pair type with a SymbolInfo class that also tracks symbol visibility. A new method, RuntimeDyld::getExportedSymbolLoadAddress, is introduced which only returns a non-zero result for exported symbols. For non-exported or non-existant symbols this method will return zero. The RuntimeDyld::getSymbolAddress method retains its current behavior, returning non-zero results for all symbols regardless of visibility. No in-tree clients of RuntimeDyld are changed. The newly introduced functionality will be used by the Orc APIs. No test case: Since this patch doesn't modify the behavior for any in-tree clients we don't have a good tool to test this with yet. Once Orc is in we can use it to write regression tests that test these changes. llvm-svn: 226341
-
Steven Wu authored
Summary: This patch add a new option to dis-allow all inline asm. Any GCC style inline asm will be reported as an error. Reviewers: rnk, echristo Reviewed By: rnk, echristo Subscribers: bob.wilson, rnk, echristo, rsmith, cfe-commits Differential Revision: http://reviews.llvm.org/D6870 llvm-svn: 226340
-
Jordan Rose authored
As mentioned in the previous commit, if a property (declared with @property) has a name that matches a special Objective-C method family, the getter picks up that family despite being declared by the property. The most correct way to solve this problem is to add the 'objc_method_family' attribute to the getter with an argument of 'none', which unfortunately requires an explicit declaration of the getter. This commit adds a note to the existing error (ARC) or warning (MRR) for such a poorly-named property that suggests the solution; if there's already a declaration of the getter, it even includes a fix-it. llvm-svn: 226339
-
Jordan Rose authored
Two years ago I added a compile-time "optimization" to ObjCMethodDecl::findPropertyDecl: exit early if the current method is part of a special Objective-C method family (like 'new' or 'init'). However, if a property (declared with @property) has a name that matches a method family, the getter picks up that family despite being declared by the property. The early exit then made ObjCMethodDecl::findPropertyDecl decide that there was no associated property, despite the method itself being marked as an accessor. This corrects that by removing the early exit. This does /not/ change the fact that such a getter is considered to return a value with a +1 retain count. The best way to eliminate this is by adding the objc_method_family(none) attribute to the getter, but unlike the existing ns_returns_not_retained that can't be applied directly to the property -- you have to redeclare the getter instead. (It'd be nice if @property just implied objc_method_family(none) for its getter, but that would be a backwards-incompatible change.) rdar://problem/19038838 llvm-svn: 226338
-
- Jan 16, 2015
-
-
David Blaikie authored
Emitting inlinable calls without debug locations (in functions with debug info, to functions with debug info) is problematic for debug info when inlining occurs. Test specifically that we don't do that in this case - thus the test isn't simply "don't crash", it's "include debug location for this call" (granted it's the wrong location - fix for that is coming) llvm-svn: 226337
-
Rui Ueyama authored
LLD parses archive file index table only at first. When it finds a symbol it is looking for is defined in a member file in an archive file, it actually reads the member from the archive file. That's done in the core linker. That's a single-thread process since the core linker is single threaded. If your command line contains a few object files and a lot of archive files (which is quite often the case), LLD hardly utilizes hardware parallelism. This patch improves parallelism by speculatively instantiating archive file members. At the beginning of the core linking, we first create a map containing all symbols defined in all members, and each time we find a new undefined symbol, we instantiate a member file containing the symbol (if such file exists). File instantiation is side effect free, so this should not affect correctness. This is a quick benchmark result. Time to link self-link LLD executable: Linux 9.78s -> 8.50s (0.86x) Windows 6.18s -> 4.51s (0.73x) http://reviews.llvm.org/D7015 llvm-svn: 226336
-
Saleem Abdulrasool authored
Generalise the base relocation handling slightly to support multiple base relocation types in PE/COFF. This is necessary to generate proper executables for WoA. Track the base relocation type from the decision that we need a base relocation to the point where we emit the base relocation into base relocation directory. Remove an outdated TODO item while in the area. llvm-svn: 226335
-
Kaelyn Takata authored
ambiguity but wasn't. In the new test case, "click" wasn't being corrected properly because Sema::ClassifyName would call CorrectTypo for "click" then later Sema::DiagnoseEmptyLookup would call CorrectTypoDelayed for the same use of "click" (the former by the parser needing to determine what the identifier is so it knows how to parse the statement, i.e. is it the beginning of a declaration or an expression). CorrectTypo would record that typo correction for "click" failed and CorrectTypoDelayed would see that and not even try to correct the typo, even though in this case CorrectTypo failed due to an ambiguity (both "Click" and "clock" having an edit distance of one from "click") that could be resolved with more information. The fix is two-fold: 1) Have CorrectTypo not record failed corrections if the reason for the failure was two or more corrections with the same edit distance, and 2) Make the CorrectionCandidateCallback used by Parser::ParseCastExpression reject FunctionDecl candidates when the next token after the identifier is a ".", "=", or "->" since functions cannot be assigned to and do not have members that can be referenced. The reason for two correction spots is that from r222549 until r224375 landed, the first correction attempt would fail completely but the second would suggest "clock" while having the note point to the declaration of "Click". llvm-svn: 226334
-
Matt Arsenault authored
These were using different naming schemes, not using multiple check prefixes and not using -LABEL. llvm-svn: 226333
-
Kevin Enderby authored
and tweak its use in llvm-objdump. Add back the test case for the -archive-headers option. llvm-svn: 226332
-
Eric Christopher authored
at the same time. Patch by David Callahan. llvm-svn: 226331
-