summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Address commentsHeejin Ahn2018-10-253-22/+15
| | | | | | | - Add llvm-mc test case (and delete the old one) - Change report_fatal_error to assertions llvm-svn: 345334
* [WebAssembly] Error out when block/loop markers mismatchHeejin Ahn2018-10-252-7/+25
| | | | | | | | | | | | | | | | Summary: Currently InstPrinter ignores if there are mismatches between block/loop and end markers by skipping the case if ControlFlowStack is empty. I guess it is better to explicitly error out in this case, because this signals invalid input. Reviewers: aardappel Subscribers: dschuff, sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D53620 llvm-svn: 345333
* [ELF] Add --{,no-}call-graph-profile-sort (enabled by default)Fangrui Song2018-10-254-15/+27
| | | | | | | | | | | | | | Summary: Add an option to disable sorting sections with call graph profile Reviewers: ruiu, Bigcheese, espindola Reviewed By: Bigcheese Subscribers: grimar, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D53683 llvm-svn: 345332
* [SystemZ] NFC reformatting in SystemZTargetTransformInfo.cppJonas Paulsson2018-10-251-5/+7
| | | | | | Some lines more than 80 characters long reformatted. llvm-svn: 345331
* Add MS ABI mangling for operator<=>.Richard Smith2018-10-253-13/+16
| | | | | | | Thanks to Cameron DaCamara at Microsoft for letting us know what their chosen mangling is here! llvm-svn: 345330
* Avoid std::map&vector in hexagon builtin code to save code sizeReid Kleckner2018-10-251-763/+808
| | | | | | | | | | | | | | | | | | | | Constructing a global std::map requires clang to generate a linear amount of code to construct the initializer list if the elements are not constexpr-constructible. std::vector is not constexpr-constructible, so this code pattern was generating large amounts of code. Also, because of PR38829, LLVM is pathologically slow on large basic blocks, and this causes slow compilation. This works around the bug and reduces code size. SemaChecking.cpp -debug-info-kind=limited: time objsize before: 1m45.023s 9.8M after: 0m25.205s 6.9M So, a 42% obj size reduction and 3.2x speedup. llvm-svn: 345329
* Avoid STMT_ and DECL_ bitcodes overlapping.Richard Smith2018-10-251-1/+3
| | | | | | | | | This doesn't appear to matter for deserialization purposes, because we always know what kind of entity (declaration or statement/expression) we're trying to load, but it makes the llvm-bcanalyzer output a lot less mysterious. llvm-svn: 345328
* [SystemZ] Improve getMemoryOpCost() to find foldable loads that are converted.Jonas Paulsson2018-10-253-42/+347
| | | | | | | | | | | | | The SystemZ backend can do arithmetic of memory by loading and then extending one of the operands. Similarly, a load + truncate can be folded into an operand. This patch improves the SystemZ TTI cost function to recognize this. Review: Ulrich Weigand https://reviews.llvm.org/D52692 llvm-svn: 345327
* DebugInfo: Explain why DW_LLE_(GNU_)startx_length is usedDavid Blaikie2018-10-251-4/+7
| | | | | | | | | | This isn't the most object-size efficient encoding, but it's the only one GDB supports for the pre-standard fission format. I've written fixes for this twice now... - so perhaps this comment will help me remember why neither of these have been committed and why I shouldn't try to write a third fix another year from now... llvm-svn: 345326
* [x86] add tests for missed load folding; NFCSanjay Patel2018-10-252-0/+149
| | | | llvm-svn: 345325
* [sanitizer] Fix mallopt interceptor.Evgeniy Stepanov2018-10-256-5/+14
| | | | | | On error, mallopt is supposed to return 0, not -1. llvm-svn: 345323
* [ELF] Don't check if symbols in .llvm.call-graph-profile are unorderableFangrui Song2018-10-252-50/+0
| | | | | | | | | | | | | | Summary: There are too many reasonable cases that would be considered unorderable. Reviewers: ruiu, espindola, Bigcheese Reviewed By: ruiu Subscribers: grimar, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D53669 llvm-svn: 345322
* [SystemZ] Improve handling and cost estimates of vector integer div/remJonas Paulsson2018-10-259-394/+1043
| | | | | | | | | | | | | | | Enable the DAG optimization that converts vector div/rem with constants into multiply+shifts sequences by expanding them early. This is needed since ISD::SMUL_LOHI is 'Custom' lowered on SystemZ, and will therefore not be available to BuildSDIV after legalization. Better cost values for these instructions based on how they will be implemented (a constant divisor is cheaper). Review: Ulrich Weigand https://reviews.llvm.org/D53196 llvm-svn: 345321
* llvm-dwarfdump: loclists: Don't expect an (albeit empty) expression for ↵David Blaikie2018-10-252-8/+9
| | | | | | LLE_base_address llvm-svn: 345320
* [Pipeliner] Ignore Artificial dependences while computing recurrences.Sumanth Gundapaneni2018-10-252-3/+110
| | | | | | | | | | The artificial dependencies are not real dependencies. In some cases, they form circuits with bigger MII. However, they are used to schedule instructions better. Differential Revision: https://reviews.llvm.org/D53450 llvm-svn: 345319
* [Pipeliner] Remove the unneeded include header(NFC).Sumanth Gundapaneni2018-10-251-1/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D53451 llvm-svn: 345318
* [X86] Change X86 backend to look for 'min-legal-vector-width' attribute ↵Craig Topper2018-10-252-28/+29
| | | | | | | | | | | | instead of 'required-vector-width' when determining whether 512-bit vectors should be legal. The required-vector-width attribute was only used for backend testing and has never been generated by clang. I believe clang is now generating min-legal-vector-width for vector uses in user code. With this I believe passing -mprefer-vector-width=256 to clang should prevent use of zmm registers in the generated assembly unless the user used a 512-bit intrinsic in their source code. llvm-svn: 345317
* [CodeGen] Remove operands from FENTRY_CALLFrancis Visoiu Mistrih2018-10-252-3/+3
| | | | | | | | | | FENTRY_CALL is actually not taking any input / output operands. The machine verifier complains now because the target description says that: * It needs 1 unknown output * It needs 1 or more variable inputs llvm-svn: 345316
* [AArch64] Create proper memoperand for multi-vector storesDavid Greene2018-10-252-1/+165
| | | | | | | | | | Include all of the store's source vector operands when creating the MachineMemOperand. Previously, we were missing the first operand, making the store size seem smaller than it really is. Differential Revision: https://reviews.llvm.org/D52816 llvm-svn: 345315
* Don't type-erase the FunctionNameType or TypeClass enums.Zachary Turner2018-10-2528-152/+186
| | | | | | | | | | This is similar to D53597, but following up with 2 more enums. After this, all flag enums should be strongly typed all the way through to the symbol files plugins. Differential Revision: https://reviews.llvm.org/D53616 llvm-svn: 345314
* Don't type-erase the SymbolContextItem enumeration.Zachary Turner2018-10-2537-117/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When we get the `resolve_scope` parameter from the SB API, it's a `uint32_t`. We then pass it through all of LLDB this way, as a uint32. This is unfortunate, because it means the user of an API never actually knows what they're dealing with. We can call it something like `resolve_scope` and have comments saying "this is a value from the `SymbolContextItem` enumeration, but it makes more sense to just have it actually *be* the correct type in the actual C++ type system to begin with. This way the person reading the code just knows what it is. The reason to use integers instead of enumerations for flags is because when you do bitwise operations on enumerations they get promoted to integers, so it makes it tedious to constantly be casting them back to the enumeration types, so I've introduced a macro to make this happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining an enumeration, it will define overloaded operators so that the returned type will be the original enum. This should address all the mechanical issues surrounding using rich enum types directly. This way, we get a better debugger experience, and new users to the codebase can get more easily acquainted with the codebase because their IDE features can help them understand what the types mean. Differential Revision: https://reviews.llvm.org/D53597 llvm-svn: 345313
* [NFC] Refactor SetBaseClasses and DeleteBaseClasses.Zachary Turner2018-10-258-94/+87
| | | | | | | | | | | | | | | | | | | | | | We currently had a 2-step process where we had to call SetBaseClassesForType and DeleteBaseClasses. Every single caller followed this exact 2-step process, and there was manual memory management going on with raw pointers. We can do better than this by storing a vector of unique_ptrs and passing this around. This makes for a cleaner API, and we only need to call one method so there is no possibility of a user forgetting to call DeleteBaseClassSpecifiers. In addition to this, it also makes for a *simpler* API. Part of why I wanted to do this is because when I was implementing the native PDB interface I had to spend some time understanding exactly what I was deleting and why. ClangAST has significant mental overhead associated with it, and reducing the API surface can go along way to making it simpler for people to understand. Differential Revision: https://reviews.llvm.org/D53590 llvm-svn: 345312
* [C++17] Reject shadowing of capture by parameter in lambdaNicolas Lesser2018-10-256-7/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change rejects the shadowing of a capture by a parameter in lambdas in C++17. ``` int main() { int a; auto f = [a](int a) { return a; }; } ``` results in: ``` main.cpp:3:20: error: a lambda parameter cannot shadow an explicitly captured entity auto f = [a](int a) { return a; }; ^ main.cpp:3:13: note: variable a is explicitly captured here auto f = [a](int a) { return a; }; ^ ``` Reviewers: rsmith Reviewed By: rsmith Subscribers: lebedev.ri, erik.pilkington, cfe-commits Differential Revision: https://reviews.llvm.org/D53595 llvm-svn: 345308
* [AArch64][GlobalISel] Simplify a legalizer test. NFC.Volkan Keles2018-10-251-116/+91
| | | | llvm-svn: 345307
* Revert "[SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03"Eric Fiselier2018-10-252-26/+2
| | | | | | This reverts commit b5d8d0de744d2c212bdb17d5c5fd4447dd14dbd2. llvm-svn: 345306
* [clang-tidy] Revert my readability-uppercase-literal-suffix check.Roman Lebedev2018-10-2524-1454/+19
| | | | | | | | | | There are some lurking issues with the handling of the SourceManager. Somehow sometimes we end up extracting completely wrong portions of the source buffer. Reverts r344772, r44760, r344758, r344755. llvm-svn: 345305
* Rebase defect report list.Nicolas Lesser2018-10-251-118/+172
| | | | llvm-svn: 345303
* Change keep-static-consts to work on static storage duration, notErich Keane2018-10-252-3/+9
| | | | | | | | | | storage class. To be more in line with what GCC does, switch the condition to be based on the Static Storage duration instead of the storage class. Change-Id: I8e959d762433cda48855099353bf3c950b9d54b8 llvm-svn: 345302
* [WebAssembly] Bitselect and min/max builtinsThomas Lively2018-10-253-0/+101
| | | | | | | | | | Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits Differential Revision: https://reviews.llvm.org/D53685 llvm-svn: 345301
* [WebAssembly] Lower to target-independent saturating addThomas Lively2018-10-252-6/+6
| | | | | | | | | | | | Summary: Goes along with D53721. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits Differential Revision: https://reviews.llvm.org/D53722 llvm-svn: 345300
* [WebAssembly] Use target-independent saturating addThomas Lively2018-10-254-26/+16
| | | | | | | | | | Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D53721 llvm-svn: 345299
* Implement Function Multiversioning for Non-ELF Systems.Erich Keane2018-10-2520-397/+938
| | | | | | | | | | | | | | | | | | | | | | | | | | Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the resolver function directly to forward the call to the proper function. This is not nearly as efficient as IFuncs of course, but is still quite useful for large functions specifically developed for certain processors. This is unfortunately still limited to x86, since it depends on __builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins. The naming for the resolver/forwarding function for cpu-dispatch was taken from ICC's implementation, which uses the unmodified name for this (no mangling additions). This is possible, since cpu-dispatch uses '.A' for the 'default' version. In 'target' multiversioning, this function keeps the '.resolver' extension in order to keep the default function keeping the default mangling. Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284 Differential Revision: https://reviews.llvm.org/D53586 llvm-svn: 345298
* [X86] Add some non-AVX512VL command lines to the *vl-vec-test-testn.ll tests.Craig Topper2018-10-252-357/+762
| | | | | | This will expose some regressions in the WIP and/or/xor promotion removal patch. llvm-svn: 345297
* [SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03Eric Fiselier2018-10-252-2/+26
| | | | | | | | | | | | | | | | | | | | Summary: When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0). Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload. For example: https://godbolt.org/z/xXJELh This patch fixes the confusion. Reviewers: rsmith, EricWF Reviewed By: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D53508 llvm-svn: 345296
* [FPEnv] Last BinaryOperator::isFNeg(...) to m_FNeg(...) changesCameron McInally2018-10-253-9/+13
| | | | | | | | | Replacing BinaryOperator::isFNeg(...) to avoid regressions when we separate FNeg from the FSub IR instruction. Differential Revision: https://reviews.llvm.org/D53650 llvm-svn: 345295
* Remove full stops from error messages for consistency.Rui Ueyama2018-10-255-8/+8
| | | | llvm-svn: 345294
* [X86] Add KNL command lines to movmsk-cmp.ll.Craig Topper2018-10-251-0/+1050
| | | | | | Some of this code looks pretty bad and we should probably still be using movmskb more with avx512f. llvm-svn: 345293
* [GlobalISel] LegalizerHelper: Fix the incorrect alignment when splitting ↵Volkan Keles2018-10-252-6/+37
| | | | | | | | | | | | | | loads/stores in narrowScalar Reviewers: dsanders, bogner, jpaquette, aemerson, ab, paquette Reviewed By: dsanders Subscribers: rovka, kristof.beyls, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D53664 llvm-svn: 345292
* CodeGen: alter CFConstantString class name for swift 5.0Saleem Abdulrasool2018-10-252-5/+10
| | | | | | | Swift 5.0 has changed the name decoration for swift symbols, using a 'S' sigil rather than 's' as in 4.2. Adopt the new convention. llvm-svn: 345291
* [LegalizeDAG] Remove dead SINT_TO_FP legalization codeSimon Pilgrim2018-10-251-54/+19
| | | | | | | | As noticed on D52965, the SINT_TO_FP i64 to f32 legalization code has been dead for years - protected by an assert. Differential Revision: https://reviews.llvm.org/D53703 llvm-svn: 345290
* fix incorrect placement of _LIBCPP_ALWAYS_INLINE in valarrayEric Fiselier2018-10-251-1/+2
| | | | llvm-svn: 345289
* [GISel] LegalizerInfo: Rename MemDesc::Size to SizeInBits to make the value ↵Volkan Keles2018-10-254-6/+6
| | | | | | | | clearer Requested in D53679. llvm-svn: 345288
* Remove accidentally committed duplicate codeAdrian Prantl2018-10-251-5/+0
| | | | llvm-svn: 345287
* [X86] Remove ProcIntelKNL and replace with a SlowPMADDWD flag to use in the ↵Craig Topper2018-10-253-8/+12
| | | | | | one place it was checked. llvm-svn: 345286
* [X86] Remove some uarch tuning flags from KNL that look to have been ↵Craig Topper2018-10-252-6/+2
| | | | | | | | | | inherited from SNB/IVB incorrectly KNL is based on a modified Silvermont core so I don't think these features apply. I think the LEA flag is probably also wrong, but I'm less sure as I barely understand the 3 LEA flags we have currently. Differential Revision: https://reviews.llvm.org/D53671 llvm-svn: 345285
* [analyzer] Move canReasonAbout from Z3ConstraintManager to SMTConstraintManagerMikhail R. Gadelha2018-10-253-43/+51
| | | | | | | | | | | | | | | | | | | Summary: This patch moves the last method in `Z3ConstraintManager` to `SMTConstraintManager`: `canReasonAbout()`. The `canReasonAbout()` method checks if a given `SVal` can be encoded in SMT. I've added a new method to the SMT API to return true if a solver can encode floating-point arithmetics and it was enough to make `canReasonAbout()` solver independent. As an annoying side-effect, `Z3ConstraintManager` is pretty empty now and only (1) creates the Z3 solver object by calling `CreateZ3Solver()` and (2) instantiates `SMTConstraintManager`. Maybe we can get rid of this class altogether in the future: a `CreateSMTConstraintManager()` method that does (1) and (2) and returns the constraint manager object? Reviewers: george.karpenkov, NoQ Reviewed By: george.karpenkov Subscribers: mehdi_amini, xazax.hun, szepet, a.sidorin, dexonsmith, Szelethus, donat.nagy, dkrupp Differential Revision: https://reviews.llvm.org/D53694 llvm-svn: 345284
* [analyzer] Fixed bitvector from model always being unsignedMikhail R. Gadelha2018-10-251-3/+5
| | | | | | | | | | | | | | | | | Summary: Getting an `APSInt` from the model always returned an unsigned integer because of the unused parameter. This was not breaking any test case because no code relies on the actual value of the integer returned here, but rather it is only used to check if a symbol has more than one solution in `getSymVal`. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin, Szelethus, donat.nagy, dkrupp Differential Revision: https://reviews.llvm.org/D53637 llvm-svn: 345283
* [AArch64][GlobalISel] Fix the LegalityPredicate for lowerIf for G_LOAD/G_STOREVolkan Keles2018-10-252-2/+23
| | | | | | | | | | | | | | | | | | | Summary: Currently, Legalizer is trying to lower G_LOAD with a vector type that has more than two elements due to the incorrect LegalityPredicate. This patch fixes the issue by removing the multiplication by 8 as `MemDesc.Size` already contains the size in bits. Reviewers: dsanders, aemerson Reviewed By: dsanders Subscribers: rovka, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D53679 llvm-svn: 345282
* Implement sized deallocation for std::allocator and friends.Eric Fiselier2018-10-257-58/+382
| | | | | | | | | | | | | | | | | | | Summary: C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own). This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown. On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem. Reviewers: ldionne, mclow.lists Reviewed By: ldionne Subscribers: rsmith, ckennelly, libcxx-commits, christof Differential Revision: https://reviews.llvm.org/D53120 llvm-svn: 345281
* [llvm-mca] Introduce a new base class for mca::Instruction, and change how ↵Andrea Di Biagio2018-10-255-79/+84
| | | | | | | | | | | | | | | | | | | | | read/write information is stored. This patch introduces a new base class for Instruction named InstructionBase. Class InstructionBase is responsible for tracking data dependencies with the help of ReadState and WriteState objects. Class Instruction now derives from InstructionBase, and adds extra information related to the `InstrStage` as well as the `RCUTokenID`. ReadState and WriteState objects are no longer unique pointers. This avoids extra heap allocation and pointer checks that weren't really needed. Now, those objects are simply stored into SmallVectors. We use a SmallVector instead of a std::vector because we expect most instructions to only have a very small number of reads and writes. By using a simple SmallVector we also avoid extra heap allocations most of the time. In a debug build, this improves the performance of llvm-mca by roughly 10% (I still have to verify the impact in performance on a release build). llvm-svn: 345280
OpenPOWER on IntegriCloud