summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Use std::unique_ptr instead of OwningPtr in the MemoryBuffer unittests.Craig Topper2014-05-182-7/+5
| | | | llvm-svn: 209102
* RAV reunification: MSPropertyRefExpr visitationAlp Toker2014-05-181-3/+6
| | | | | | | r179585 introduced different MSPropertyRefExpr visitation for RAV and DRAV that appears to have been unintentional. Let's use the more complete one. llvm-svn: 209101
* RAV reunification: merge r162133 (visit the TypeLoc when RecursiveASTVisitor ↵Alp Toker2014-05-181-1/+3
| | | | | | visits a CompoundLiteralExpr) llvm-svn: 209100
* profile: explicitly initialize file name in the testSaleem Abdulrasool2014-05-181-0/+5
| | | | | | | | | | | | The instrprofile-write-file-only test was failing on the builtbots. The runtime library initialization is explicitly being discarded to avoid the atexit hook. However, this would also prevent the filename from being initialized. Thus, when the write file was invoked, the filename would not be setup, and the test would fail as the profiling data would never be written out. Explicitly initialize the filename to ensure that the data is written out when requested. This should hopefully finally get the build bots all green again. llvm-svn: 209099
* profile: adjust flags for libdlSaleem Abdulrasool2014-05-181-2/+2
| | | | | | | | dlopen expects that the flags contains RTLD_LAZY or RTLD_NOW. RTLD_LAZY will resolve the symbol on first use, and is generally preferred due to efficiency. Add this to fix the test failure on the build bots. llvm-svn: 209098
* profile: add logging on failureSaleem Abdulrasool2014-05-181-1/+30
| | | | | | | Add logging to report any failures that may occur on calls to libdl. Without this, it is difficult to identify the actual problem if the test fails. llvm-svn: 209097
* profile: explicitly link against libdlSaleem Abdulrasool2014-05-181-2/+2
| | | | | | | | Add an explicit link against libdl. libdl may not be indirectly pulled on some Linux hosts. Explicitly link against it. This should hopefully improve the state of the build bots. llvm-svn: 209096
* assembly: support symbol definitions for COFFSaleem Abdulrasool2014-05-181-1/+10
| | | | | | | | | Extend the function definition macros further to support COFF object emission. The function definition in COFF includes the type and storage class in the symbol definition context. This is needed to make the assembly routines possible to be built for COFF environments (i.e. Windows). llvm-svn: 209095
* assembly: rework HIDDEN_DIRECTIVE to accomodate COFFSaleem Abdulrasool2014-05-181-5/+5
| | | | | | | | Rename the HIDDEN_DIRECTIVE macro to HIDDEN and give it a parameter providing the name of the symbol to be given hidden visibility. This makes the macros more amenable to COFF. llvm-svn: 209094
* Ongoing RAV reunificationAlp Toker2014-05-181-10/+10
| | | | | | | | | | * Shuffle around code to reduce delta between the two RAVs. * Merge r189185 that was applied only to one of the RAVs and became apparent during the unification work. * Fix Enqueue data recursion typo. Our delta is down to +-579! llvm-svn: 209093
* Format the two RecursiveASTVisitorsAlp Toker2014-05-182-1968/+1802
| | | | | | | | | | | | | Apply current ToT clang-format on the two RAVs to reduce delta and help identify differences between the two. We lose a little pretty formatting in the headers but that's the price to pay so we can diff these two files effectively and look to a future where we don't have to maintain two copies of this code. Formatting and whitespace only. llvm-svn: 209092
* Begin RAV reunification: s/DataRecursiveASTVisitor/RecursiveASTVisitor/Alp Toker2014-05-181-53/+59
| | | | | | | | | | | | | | | | Define a macro to reduce the delta between RecursiveASTVisitor and DataRecursiveASTVisitor. Some years ago, someone thought it was a good idea to copy the entire RAV to support cursor visitation in libclang. Since then the two have diverged needlessly and the rest is history. This series of commits aims to reduce delta between the two so that we can reason about their differences, apply bugfixes that were only made to one but not the other, and ultimately find a way to unify two two chunks of code. llvm-svn: 209091
* Remove historical Unicode TODOsAlp Toker2014-05-181-16/+3
| | | | | | There's no immediate demand or plan to work on these. llvm-svn: 209090
* ARM: make libcall setup more table drivenSaleem Abdulrasool2014-05-181-161/+100
| | | | | | | | | Rather than create a series of function calls to setup the library calls, create a table with the information and just use the table to drive the configuration of the library calls. This makes it easier to both inspect the list as well as to modify it. NFC. llvm-svn: 209089
* Options: Use erase_if to remove Args from the list.Benjamin Kramer2014-05-182-9/+4
| | | | | | | While there make getOption return a const reference so we don't have to put it on the stack when calling methods on it. No functionality change. llvm-svn: 209088
* Remove unused diagnostic.Benjamin Kramer2014-05-181-2/+0
| | | | llvm-svn: 209087
* Driver: force restricted IT blocks for Windows on ARMSaleem Abdulrasool2014-05-182-0/+9
| | | | | | | Windows on ARM expects ARMv8 (restricted IT) conditional instructions only. Force enable the restricted IT mode via the backend option when targeting WoA. llvm-svn: 209086
* ARM: improve WoA ABI conformance for frame registerSaleem Abdulrasool2014-05-183-3/+67
| | | | | | | | | Windows on ARM uses R11 for the frame pointer even though the environment is a pure Thumb-2, thumb-only environment. Replicate this behaviour to improve Windows ABI compatibility. This register is used for fast stack walking, and thus is part of the Windows ABI. llvm-svn: 209085
* ARM: consolidate frame pointer register knowledgeSaleem Abdulrasool2014-05-181-3/+5
| | | | | | | | | | | Use the ARMBaseRegisterInfo to query the frame register. The base register info is aware of the frame register that is used for the frame pointer. Use that to determine the frame register rather than duplicating the knowledge. Although, the code path is slightly different in that it may return SP, that can only occur if the frame pointer has been omitted in the machine function, which is supposed to contain the desired value in that case. llvm-svn: 209084
* [C++11] Use 'nullptr'. Lex edition.Craig Topper2014-05-1717-227/+239
| | | | llvm-svn: 209083
* Target: remove old constructors for CallLoweringInfoSaleem Abdulrasool2014-05-1719-256/+190
| | | | | | | | | | This is mostly a mechanical change changing all the call sites to the newer chained-function construction pattern. This removes the horrible 15-parameter constructor for the CallLoweringInfo in favour of setting properties of the call via chained functions. No functional change beyond the removal of the old constructors are intended. llvm-svn: 209082
* Target: add support to build CallLoweringInfoSaleem Abdulrasool2014-05-171-0/+86
| | | | | | | | | | | Rather than introducing an auxiliary CallLoweringInfoBuilder, add the methods to do chained function construction directly to CallLoweringInfo. This reduces the monstrous 15-parameter constructor into a series of simpler (for some definition of simpler) functions that control particular aspects of the call. The old interfaces can be completely removed once callers are moved to the new chained constructor pattern. llvm-svn: 209081
* Target: change member from reference to pointerSaleem Abdulrasool2014-05-176-10/+15
| | | | | | | | | This is a preliminary step to help ease the construction of CallLoweringInfo. Changing the construction to a chained function pattern requires that the parameter be nullable. However, rather than copying the vector, save a pointer rather than the reference to permit a late binding of the arguments. llvm-svn: 209080
* ARM: whitespaceSaleem Abdulrasool2014-05-171-3/+3
| | | | | | Remove some whitespace. NFC. llvm-svn: 209079
* Update for llvm api change.Rafael Espindola2014-05-175-12/+12
| | | | llvm-svn: 209077
* Use create methods since msvc doesn't handle delegating constructors.Rafael Espindola2014-05-1711-40/+62
| | | | llvm-svn: 209076
* Handle ConstantAggregateZero when upgrading global_ctors.Rafael Espindola2014-05-173-6/+12
| | | | llvm-svn: 209075
* Update for llvm api change.Rafael Espindola2014-05-175-23/+19
| | | | llvm-svn: 209074
* Reduce abuse of default values in the GlobalAlias constructor.Rafael Espindola2014-05-1711-28/+52
| | | | | | This is in preparation for adding an optional offset. llvm-svn: 209073
* Introduce the concept of a "display name" for typesEnrico Granata2014-05-1728-33/+190
| | | | | | | | | | | | | | | | | | | | | | Rationale: Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as std::__1::vector<int, std::__1::allocator<.... rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code Proposed solution: Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type Caveats: - for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet. - while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters llvm-svn: 209072
* [C++11] Use 'nullptr'. ASTMatchers edition.Craig Topper2014-05-174-24/+24
| | | | llvm-svn: 209070
* [C++11] Use 'nullptr'. Driver edition.Craig Topper2014-05-177-66/+69
| | | | llvm-svn: 209069
* CodeGen: remove MinGW and Cygwin legacy entriesSaleem Abdulrasool2014-05-171-2/+0
| | | | | | | | | These are now treated as environments. Remove references to these enumeration values in order to clean up the unused enumeration entries in LLVM. The target normalisation prior to tool invocation should ensure that the old values continue to function properly. llvm-svn: 209068
* Revert r209049 and r209065, "Add support for combining GEPs across PHI nodes"NAKAMURA Takumi2014-05-172-122/+0
| | | | | | It broke clang selfhosting even after r209065. llvm-svn: 209067
* MachO: Add comments describing section flags/attrsDavid Majnemer2014-05-171-0/+48
| | | | | | | | | | | | | | When pruning superfluous MachO structure definitions, I chose to keep the most generically useful which is why Support's definitions won over the ones in MC. However, the MC copy had some useful comments describing some of the field values. Bring these back to the copy in Support. While doing this, fill in some of the underdocumented definitions as well. llvm-svn: 209066
* Fix for sanitizer crash introduced in r209049Louis Gerbarg2014-05-171-1/+8
| | | | | | | | | | This patch fixes 3 issues introduced by r209049 that only showed up in on the sanitizer buildbots. One was a typo in a compare. The other is a check to confirm that the single differing value in the two incoming GEPs is the same type. The final issue was the the IRBuilder under some circumstances would build PHIs in the middle of the block. llvm-svn: 209065
* Target: Replace getSection().empty() with hasSection()David Majnemer2014-05-171-1/+1
| | | | | | No functional change, just a small cleanup. llvm-svn: 209064
* [Mips] Fix calculation of initial GOT entry value when this entry isSimon Atanasyan2014-05-172-1/+74
| | | | | | referenced by a local symbol. llvm-svn: 209063
* Track clang changes from r209061Alp Toker2014-05-171-2/+1
| | | | llvm-svn: 209062
* Provide and use a safe Token::getRawIdentifier() accessorAlp Toker2014-05-178-33/+28
| | | | llvm-svn: 209061
* More fixes for isBetterOverloadCandidate not being a strict weak ordering. TheRichard Smith2014-05-172-19/+26
| | | | | | bug was obvious from inspection, figuring out a way to test it was... less so. llvm-svn: 209060
* [objcmt] Don't wrap a PCH generation action with a ObjCMigrateAction one, it ↵Argyrios Kyrtzidis2014-05-172-1/+14
| | | | | | | | messes up the PCH file. rdar://16941811 llvm-svn: 209059
* test: fix copy-paste mistakeSaleem Abdulrasool2014-05-171-1/+1
| | | | | | Accidental over-quoting of the match string. llvm-svn: 209058
* ARM: use the proper target object format for WoASaleem Abdulrasool2014-05-172-1/+17
| | | | | | | | WoA uses COFF, not ELF. ARMISelLowering::createTLOF would previously return ELF for any non-MachO platform. This was a missed site when the original change for target format support for Windows on ARM was done. llvm-svn: 209057
* [x86] Fix a bad predicate I spotted by inspection -- pshufhw and pshuflwChandler Carruth2014-05-172-3/+3
| | | | | | | | | | were added in SSE2, no SSSE3. Found this while auditing all uses of SSSE3 in the X86 target. I don't actually expect this to make a significant difference on anything and I don't have any detailed test cases but I updated the existing test cases that already covered some of this code path. llvm-svn: 209056
* Switch to a more efficient expression of this check.Richard Smith2014-05-171-20/+24
| | | | llvm-svn: 209055
* Correct incoherent function versus function template partial ordering for ↵Richard Smith2014-05-174-26/+52
| | | | | | conversion operators (the comparison could claim that two conversion operators are both better than each other). Actually implement DR495, rather than passing its test by chance because the declarations happened to be in the "lucky" order. llvm-svn: 209054
* InstrProf: Support profiling dlopen'd shared librariesDuncan P. N. Exon Smith2014-05-177-78/+148
| | | | | | | | | | | | | | | | | | Shared objects are hard. After this commit, we do the right thing when profiling two separate shared objects that have been dlopen'd with `RTLD_LOCAL`, when the main executable is *not* being profiled. This mainly simplifies the writer logic. - At initialization, determine the output filename and truncate the file. Depending on whether shared objects can see each other, this may happen multiple times. - At exit, each executable writes its own profile in append mode. <rdar://problem/16918688> llvm-svn: 209053
* Tweak diagnostic wording for init list narrowingAlp Toker2014-05-1713-120/+120
| | | | | | | | | The conventional form is '<action> to silence this warning'. Also call the diagnostic an 'issue' rather than a 'message' because the latter term is more widely used with reference to message expressions. llvm-svn: 209052
* Update how we create our MCSymbolizer to keep working correctlyJason Molenda2014-05-171-1/+5
| | | | | | | | on arm64 binaries after the llvm r206063 changes. Patch written by Jim Ingham and Lang Hames. <rdar://problem/16935671> llvm-svn: 209051
OpenPOWER on IntegriCloud