summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [SROA] Use the members for New{Begin,End}Offset in the rewrite helpersChandler Carruth2014-02-261-14/+8
| | | | | | | | | | | | | | | rather than passing them as arguments. While I generally prefer actual arguments, in this case the readability loss is substantial. By using members we avoid repeatedly calculating the offsets, and once we're using members it is useful to ensure that those names *always* refer to the original-alloca-relative new offset for a rewritten slice. No functionality changed. Follow-up refactoring, all toward getting the address space patch merged. llvm-svn: 202228
* [SROA] Compute the New{Begin,End}Offset values once for each allocaChandler Carruth2014-02-261-40/+24
| | | | | | | | | | | | | | slice being rewritten. We had the same code scattered across most of the visits. Instead, compute the new offsets and the slice size once when we start to visit a particular slice, and use the member variables from then on. This reduces quite a bit of code duplication. No functionality changed. Refactoring inspired to make it easier to apply the address space patch to SROA. llvm-svn: 202227
* clang/test/CodeGenCXX/debug-info-varargs.cpp: Appease msvc with ↵NAKAMURA Takumi2014-02-261-1/+1
| | | | | | %itanium_abi_triple. llvm-svn: 202226
* Use StringRef in raw_fd_ostream constructorBen Langmuir2014-02-262-4/+3
| | | | llvm-svn: 202225
* [SROA] Fix PR18615 with some long overdue simplifications to the boundsChandler Carruth2014-02-262-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | | checking in SROA. The primary change is to just rely on uge for checking that the offset is within the allocation size. This removes the explicit checks against isNegative which were terribly error prone (including the reversed logic that led to PR18615) and prevented us from supporting stack allocations larger than half the address space.... Ok, so maybe the latter isn't *common* but it's a silly restriction to have. Also, we used to try to support a PHI node which loaded from before the start of the allocation if any of the loaded bytes were within the allocation. This doesn't make any sense, we have never really supported loading or storing *before* the allocation starts. The simplified logic just doesn't care. We continue to allow loading past the end of the allocation in part to support cases where there is a PHI and some loads are larger than others and the larger ones reach past the end of the allocation. We could solve this a different and more conservative way, but I'm still somewhat paranoid about this. llvm-svn: 202224
* Remove 'tctx->name' from a logical statement since it is a pointer and alwaysRichard Trieu2014-02-261-1/+1
| | | | | | is converted to a true value. Detected by Clang's improved -Wbool-conversion llvm-svn: 202223
* Remove spurious emacs major mode marker, these should only go on .h files.Nick Lewycky2014-02-261-1/+1
| | | | llvm-svn: 202222
* 80-col.Eric Christopher2014-02-261-1/+2
| | | | llvm-svn: 202221
* Formatting fixups.Eric Christopher2014-02-261-2/+2
| | | | llvm-svn: 202220
* 80-col and bad line ending fixups.Eric Christopher2014-02-261-8/+8
| | | | llvm-svn: 202219
* Delete two declared overloads of CallInst::CallInst that are never defined ↵Nick Lewycky2014-02-261-4/+0
| | | | | | or used. No functionality change. llvm-svn: 202218
* [PECOFF] Add a utility function to add DIR32 relocation.Rui Ueyama2014-02-262-4/+16
| | | | llvm-svn: 202217
* PR16074, implement warnings to catch pointer to boolean true and pointer toRichard Trieu2014-02-2621-96/+393
| | | | | | | | | | | | | | | | | | | | | | | | | | | | null comparison when the pointer is known to be non-null. This catches the array to pointer decay, function to pointer decay and address of variables. This does not catch address of function since this has been previously used to silence a warning. Pointer to bool conversion is under -Wbool-conversion. Pointer to null comparison is under -Wtautological-pointer-compare, a sub-group of -Wtautological-compare. void foo() { int arr[5]; int x; // warn on these conditionals if (foo); if (arr); if (&x); if (foo == null); if (arr == null); if (&x == null); if (&foo); // no warning } llvm-svn: 202216
* [PECOFF] Fix DLLCharacteristics field.Rui Ueyama2014-02-263-5/+5
| | | | | | IMAGE_DLL_CHARACTERISTICS_NO_SEH flag should be set only when SEH is disabled. llvm-svn: 202215
* Implement LWG issue 2306: match_results::reference should be value_type&, ↵Marshall Clow2014-02-263-4/+4
| | | | | | not const value_type&. This is a general move by the LWG to have the reference type of read-only containers be a non-const reference; however, there are no methods that return a non-const reference to a match_result entry, so there's no worries about getting a non-const reference to a constant object. llvm-svn: 202214
* Constify the Optnone checks in IR passes.Paul Robinson2014-02-264-8/+8
| | | | llvm-svn: 202213
* [analyzer] NonNullParamChecker: don't freak out about nested transparent_unions.Jordan Rose2014-02-262-2/+49
| | | | | | | | | For now, just ignore them. Later, we could try looking through LazyCompoundVals, but we at least shouldn't crash. <rdar://problem/16153464> llvm-svn: 202212
* Add -Wabsolute-value, warnings about absolute value functions.Richard Trieu2014-02-267-0/+1200
| | | | | | | | | | | | | | | | | | The warnings fall into three groups. 1) Using an absolute value function of the wrong type, for instance, using the int absolute value function when the argument is a floating point type. 2) Using the improper sized absolute value function, for instance, using abs when the argument is a long long. llabs should be used instead. From these two cases, an implicit conversion will occur which may cause unexpected behavior. Where possible, suggest the proper absolute value function to use, and which header to include if the function is not available. 3) Taking the absolute value of an unsigned value. In addition to this warning, suggest to remove the function call. This usually indicates a logic error since the programmer assumed negative values would have been possible. llvm-svn: 202211
* Simplify base64 routine a bit.Rui Ueyama2014-02-251-2/+2
| | | | llvm-svn: 202210
* Exception handling docs: Describe landingpad clauses' meanings in more detailMark Seaborn2014-02-251-6/+55
| | | | | | | | | | | | | | | | The original text is very terse, so I've expanded on it. Specifically, in the original text: * "The selector value is a positive number if the exception matched a type info" -- It wasn't clear that this meant "if the exception matched a 'catch' clause". * "If nothing is matched, the behavior of the program is `undefined`_." -- It's actually implementation-defined in C++ rather than undefined, as the new text explains. llvm-svn: 202209
* Address review comments for r202185, no functionality changes.Adrian Prantl2014-02-252-12/+11
| | | | llvm-svn: 202208
* Add DIUnspecifiedParameter, so we can pretty-print it.Adrian Prantl2014-02-252-0/+13
| | | | | | This will be used for testcases in CFE. llvm-svn: 202207
* fix crash in SmallDenseMap copy constructorDuncan P. N. Exon Smith2014-02-252-1/+29
| | | | | | | | | Prevent a crash in the SmallDenseMap copy constructor whenever the other map is not in small mode. <rdar://problem/14292693> llvm-svn: 202206
* <rdar://problem/15593026>Enrico Granata2014-02-251-18/+30
| | | | | | Fix the algorithm used to detect a loop in a std::list llvm-svn: 202205
* Use DataLayout from the module when easily available.Rafael Espindola2014-02-2522-30/+58
| | | | | | | | | | | | | | | | | Eventually DataLayoutPass should go away, but for now that is the only easy way to get a DataLayout in some APIs. This patch only changes the ones that have easy access to a Module. One interesting issue with sometimes using DataLayoutPass and sometimes fetching it from the Module is that we have to make sure they are equivalent. We can get most of the way there by always constructing the pass with a Module. In fact, the pass could be changed to point to an external DataLayout instead of owning one to make this stricter. Unfortunately, the C api passes a DataLayout, so it has to be up to the caller to make sure the pass and the module are in sync. llvm-svn: 202204
* Mark LWG issue 2299 as complete. No code changes; libc++ already implements ↵Marshall Clow2014-02-251-1/+1
| | | | | | this. llvm-svn: 202203
* Attempt to unbreak an MSVC buildbot by switching to %llc_dwarf.Adrian Prantl2014-02-251-1/+1
| | | | llvm-svn: 202202
* DwarfDebug: Avoid emitting an empty debug_aranges section when aranges are ↵David Blaikie2014-02-252-1/+5
| | | | | | disabled llvm-svn: 202201
* Hoist culling of -Wunreachable-code from headers before we even run the ↵Ted Kremenek2014-02-251-6/+10
| | | | | | analysis. llvm-svn: 202200
* Address review comments for r202188.Adrian Prantl2014-02-254-37/+30
| | | | | | | | | This is refactoring / simplifying code, updating comments and enabling the testcase on non-x86 platforms. No functionality change. llvm-svn: 202199
* Fix resetting the DataLayout in a Module.Rafael Espindola2014-02-254-11/+38
| | | | | | | | | | | | | | | No tool does this currently, but as everything else in a module we should be able to change its DataLayout. Most of the fix is in DataLayout to make sure it can be reset properly. The test uses Module::setDataLayout since the fact that we mutate a DataLayout is an implementation detail. The module could hold a OwningPtr<DataLayout> and the DataLayout itself could be immutable. Thanks to Philip Reames for pushing me in the right direction. llvm-svn: 202198
* Restore string match behavior following changes in r202018Alp Toker2014-02-251-2/+2
| | | | llvm-svn: 202197
* [reassociate] Switch two std::sort calls into std::stable_sort calls asChandler Carruth2014-02-251-2/+2
| | | | | | | | | | | | | | | their inputs come from std::stable_sort and they are not total orders. I'm not a huge fan of this, but the really bad std::stable_sort is right at the beginning of Reassociate. After we commit to stable-sort based consistent respect of source order, the downstream sorts shouldn't undo that unless they have a total order or they are used in an order-insensitive way. Neither appears to be true for these cases. I don't have particularly good test cases, but this jumped out by inspection when looking for output instability in this pass due to changes in the ordering of std::sort. llvm-svn: 202196
* R600: Don't unconditionally unroll loops with private memory accessesTom Stellard2014-02-251-3/+7
| | | | | | | This causes the size of the scrypt kernel to explode and eats all the memory on some systems. llvm-svn: 202195
* R600/SI: Custom select 64-bit ADDTom Stellard2014-02-255-36/+75
| | | | llvm-svn: 202194
* [SROA] Add an off-by-default *strict* inbounds check to SROA. I had SROAChandler Carruth2014-02-251-0/+42
| | | | | | | | | | implemented this way a long time ago and due to the overwhelming bugs that surfaced, moved to a much more relaxed variant. Richard Smith would like to understand the magnitude of this problem and it seems fairly harmless to keep some flag-controlled logic to get the extremely strict behavior here. I'll remove it if it doesn't prove useful. llvm-svn: 202193
* Account for 128-bit integer operations in PPCCTRLoopsHal Finkel2014-02-252-6/+42
| | | | | | | We need to abort the formation of counter-register-based loops where there are 128-bit integer operations that might become function calls. llvm-svn: 202192
* Don't try to set a dummy DataLayout. It is parsed now.Rafael Espindola2014-02-251-2/+2
| | | | llvm-svn: 202191
* Store a DataLayout in Module.Rafael Espindola2014-02-259-24/+62
| | | | | | | | | | | | | | Now that DataLayout is not a pass, store one in Module. Since the C API expects to be able to get a char* to the datalayout description, we have to keep a std::string somewhere. This patch keeps it in Module and also uses it to represent modules without a DataLayout. Once DataLayout is mandatory, we should probably move the string to DataLayout itself since it won't be necessary anymore to represent the special case of a module without a DataLayout. llvm-svn: 202190
* Switch debugserver to detach on error by default, and change the flag to ↵Jim Ingham2014-02-251-5/+10
| | | | | | | | | kill-on-error. Also fix the bug where lldb prints: "Got a connection and launched debugserver" rather than the name of the process it actually launched. llvm-svn: 202189
* Debug info: Support variadic functions.Adrian Prantl2014-02-255-29/+141
| | | | | | | | | | | | | | Variadic functions have an unspecified parameter tag after the last argument. In IR this is represented as an unspecified parameter in the subroutine type. Paired commit with CFE r202185. rdar://problem/13690847 This re-applies r202184 + a bugfix in DwarfDebug's argument handling. llvm-svn: 202188
* Revert "Debug info: Support variadic functions."Adrian Prantl2014-02-255-128/+22
| | | | | | This reverts commit r202184 because of buildbot breakage. llvm-svn: 202187
* Remove outdated comments.Manman Ren2014-02-251-1/+1
| | | | llvm-svn: 202186
* Debug info: Generate debug info for variadic functions.Adrian Prantl2014-02-252-0/+40
| | | | | | | | Paired commit with LLVM. rdar://problem/13690847 llvm-svn: 202185
* Debug info: Support variadic functions.Adrian Prantl2014-02-255-22/+128
| | | | | | | | | | | | Variadic functions have an unspecified parameter tag after the last argument. In IR this is represented as an unspecified parameter in the subroutine type. Paired commit with CFE. rdar://problem/13690847 llvm-svn: 202184
* Update for llvm api change.Rafael Espindola2014-02-255-10/+13
| | | | llvm-svn: 202183
* Add preprocessed output to ccc-analyzer's accepted language map.Ted Kremenek2014-02-251-1/+4
| | | | llvm-svn: 202182
* Pretty Printer: Print constexpr and ref qualifiers. Don't print return types ↵Benjamin Kramer2014-02-255-18/+28
| | | | | | on destructors. llvm-svn: 202181
* Make TestStdCXXDisassembly.StdCXXDisassembleTestCase work with libc++Enrico Granata2014-02-251-4/+5
| | | | | | <rdar://problem/16115219> llvm-svn: 202180
* Pass the sparc architecture variant to the assembler.Roman Divacky2014-02-252-0/+6
| | | | llvm-svn: 202179
OpenPOWER on IntegriCloud