summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove a superfluous semicolonMartin Storsjo2018-07-201-1/+1
| | | | llvm-svn: 337599
* [COFF] Sort .reloc before all other discardable sectionsMartin Storsjo2018-07-202-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a binary is stripped, which can remove discardable sections (except for the .reloc section, which also is marked as discardable as it isn't loaded at runtime, only read by the loader), the .reloc section should be first of them, in order not to create gaps in the image. Previously, binaries with relocations were broken if they were stripped by GNU binutils strip. Trying to execute such binaries produces an error about "xx is not a valid win32 application". This fixes GNU binutils bug 23348. Prior to SVN r329370 (which didn't intend to have functional changes), the code for moving discardable sections to the end didn't clearly express how other discardable sections should be ordered compared to .reloc, but the change retained the exact same end result as before. After SVN r329370, the code (and comments) more clearly indicate that it tries to make the .reloc section the absolutely last one; this patch changes that. This matches how GNU binutils ld sorts .reloc compared to dwarf debug info sections. Differential Revision: https://reviews.llvm.org/D49351 Signed-off-by: Martin Storsjö <martin@martin.st> llvm-svn: 337598
* Make check-llvm depend on llvm-undnameReid Kleckner2018-07-201-0/+1
| | | | llvm-svn: 337597
* [Demangler] Correctly factor in assignment when allocating.Zachary Turner2018-07-201-24/+29
| | | | | | | | | Incidentally all allocations that we currently perform were properly aligned, but this was only an accident. Thanks to Erik Pilkington for catching this. llvm-svn: 337596
* [ORC] Add new symbol lookup methods to ExecutionSessionBase in preparation forLang Hames2018-07-209-512/+749
| | | | | | | | | | | | deprecating SymbolResolver and AsynchronousSymbolQuery. Both lookup overloads take a VSO search order to perform the lookup. The first overload is non-blocking and takes OnResolved and OnReady callbacks. The second is blocking, takes a boolean flag to indicate whether to wait until all symbols are ready, and returns a SymbolMap. Both overloads take a RegisterDependencies function to register symbol dependencies (if any) on the query. llvm-svn: 337595
* [ORC] Simplify VSO::lookupFlags to return the flags map.Lang Hames2018-07-2013-105/+96
| | | | | | | | | | | This discards the unresolved symbols set and returns the flags map directly (rather than mutating it via the first argument). The unresolved symbols result made it easy to chain lookupFlags calls, but such chaining should be rare to non-existant (especially now that symbol resolvers are being deprecated) so the simpler method signature is preferable. llvm-svn: 337594
* [ORC] Replace SymbolResolvers in the new ORC layers with search orders on VSOs.Lang Hames2018-07-2015-303/+376
| | | | | | | | | | | | | | | A search order is a list of VSOs to be searched linearly to find symbols. Each VSO now has a search order that will be used when fixing up definitions in that VSO. Each VSO's search order defaults to just that VSO itself. This is a first step towards removing symbol resolvers from ORC altogether. In practice symbol resolvers tended to be used to implement a search order anyway, sometimes with additional programatic generation of symbols. Now that VSOs support programmatic generation of definitions via fallback generators, search orders provide a cleaner way to achieve the desired effect (while removing a lot of boilerplate). llvm-svn: 337593
* [Demangler] Add missing overridesBenjamin Kramer2018-07-201-3/+3
| | | | | | -Winconsistent-missing-override complains about this. llvm-svn: 337592
* Fix a few warnings and style issues in MS demangler.Zachary Turner2018-07-202-20/+24
| | | | | | Also remove a broken test case. llvm-svn: 337591
* [X86] Remove isel patterns for MOVSS/MOVSD ISD opcodes with integer types.Craig Topper2018-07-208-153/+83
| | | | | | | | | | Ideally our ISD node types going into the isel table would have types consistent with their instruction domain. This prevents us having to duplicate patterns with different types for the same instruction. Unfortunately, it seems our shuffle combining is currently relying on this a little remove some bitcasts. This seems to enable some switching between shufps and shufd. Hopefully there's some way we can address this in the combining. Differential Revision: https://reviews.llvm.org/D49280 llvm-svn: 337590
* [X86] Remove what appear to be unnecessary uses of DCI.CombineToCraig Topper2018-07-201-19/+13
| | | | | | | | | | CombineTo is most useful when you need to replace multiple results, avoid the worklist management, or you need to something else after the combine, etc. Otherwise you should be able to just return the new node and let DAGCombiner go through its usual worklist code. All of the places changed in this patch look to be standard cases where we should be able to use the more stand behavior of just returning the new node. Differential Revision: https://reviews.llvm.org/D49569 llvm-svn: 337589
* Fix linker failure with Any.Zachary Turner2018-07-201-1/+4
| | | | | | | This is due to a difference in MS ABI which is why I didn't see it locally. The included fix should work on all compilers. llvm-svn: 337588
* [CUDA] Provide integer SIMD functions for CUDA-9.2Artem Belevich2018-07-202-1/+429
| | | | | | | | | | | | | | | | | | | | | CUDA-9.2 made all integer SIMD functions into compiler builtins, so clang no longer has access to the implementation of these functions in either headers of libdevice and has to provide its own implementation. This is mostly a 1:1 mapping to a corresponding PTX instructions with an exception of vhadd2/vhadd4 that don't have an equivalent instruction and had to be implemented with a bit hack. Performance of this implementation will be suboptimal for SM_50 and newer GPUs where PTXAS generates noticeably worse code for the SIMD instructions compared to the code it generates for the inline assembly generated by nvcc (or used to come with CUDA headers). Differential Revision: https://reviews.llvm.org/D49274 llvm-svn: 337587
* [llvm-mca][x86] Add movsx/movzx instructions to general x86_64 resource testsSimon Pilgrim2018-07-2010-10/+700
| | | | llvm-svn: 337586
* Prevent Scoped Enums from being Integral constant expressions:Erich Keane2018-07-202-1/+15
| | | | | | | | | | | | | | | | Discovered because of: https://bugs.llvm.org/show_bug.cgi?id=38235 It seems to me that a scoped enum should NOT be an integral constant expression without a cast, so this seems like a sensical change. Attributes that check for an integer parameter simply use this function to ensure that they have an integer, so it was previously allowing a scoped enum. Also added a test based on Richard's feedback to ensure that case labels still work. Differential Revision: https://reviews.llvm.org/D49599 llvm-svn: 337585
* Add a Microsoft Demangler.Zachary Turner2018-07-2010-2/+2259
| | | | | | | | | | | | | This adds initial support for a demangling library (LLVMDemangle) and tool (llvm-undname) for demangling Microsoft names. This doesn't cover 100% of cases and there are some known limitations which I intend to address in followup patches, at least until such time that we have (near) 100% test coverage matching up with all of the test cases in clang/test/CodeGenCXX/mangle-ms-*. Differential Revision: https://reviews.llvm.org/D49552 llvm-svn: 337584
* [Any] Fix a typo: didn't use the correct argumentPhilip Pfaffe2018-07-201-1/+1
| | | | llvm-svn: 337583
* Merge changes to ItaniumDemangle over to libcxxabi.Zachary Turner2018-07-204-155/+343
| | | | | | | | | | | ItaniumDemangle had a small NFC refactor to make some of its code reusable by the newly added Microsoft demangler. To keep the libcxxabi demangler as close as possible to the master copy this refactor is being merged over. Differential Revision: https://reviews.llvm.org/D49575 llvm-svn: 337582
* [MemorySSA] Add API to update MemoryPhis, following CFG changes.Alina Sbirlea2018-07-203-11/+49
| | | | | | | | | | | | | | | | Summary: When splitting predecessors in BasicBlockUtils, we create a new block as an immediate predecessor of the original BB, then we connect a given set of predecessors to the new block. The API in this patch will be used to update MemoryPhis for this CFG change. If all predecessors are being moved, we move the MemoryPhi directly. Otherwise we create a new MemoryPhi in the NewBB and populate its incoming values, while deleting them from BB's Phi. [Split from D45299 for easier review] Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D49156 llvm-svn: 337581
* [CodeGen][ObjC] Make copying and disposing of a non-escaping blockAkira Hatanaka2018-07-204-6/+74
| | | | | | | | | | | | | | | | | | | | | | no-ops. A non-escaping block on the stack will never be called after its lifetime ends, so it doesn't have to be copied to the heap. To prevent a non-escaping block from being copied to the heap, this patch sets field 'isa' of the block object to NSConcreteGlobalBlock and sets the BLOCK_IS_GLOBAL bit of field 'flags', which causes the runtime to treat the block as if it were a global block (calling _Block_copy on the block just returns the original block and calling _Block_release is a no-op). Also, a new flag bit 'BLOCK_IS_NOESCAPE' is added, which allows the runtime or tools to distinguish between true global blocks and non-escaping blocks. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D49303 llvm-svn: 337580
* On Darwin switch from the `VM_MEMORY_ANALYSIS_TOOL` VM tag toDan Liew2018-07-201-1/+7
| | | | | | | | | | | | | `VM_MEMORY_SANITIZER`. It turns out that `VM_MEMORY_ANALYSIS_TOOL` is already reserved for use by other tools so switch to a tag reserved for use by the Sanitizers. rdar://problem/41969783 Differential Revision: https://reviews.llvm.org/D49603 llvm-svn: 337579
* [X86][XOP] Fix SUB constant folding for VPSHA/VPSHL shift loweringSimon Pilgrim2018-07-206-225/+161
| | | | | | | | We can safely use getConstant here as we're still lowering, which allows constant folding to kick in and simplify the vector shift codegen. Noticed while working on D49562. llvm-svn: 337578
* [MSan] Hotfix compilationAlexander Potapenko2018-07-201-0/+1
| | | | | | Make sure NewSI is used in materializeStores() llvm-svn: 337577
* Change bool_constant to integral_constant.Zachary Turner2018-07-201-1/+2
| | | | | | bool_constant is C++17. llvm-svn: 337576
* [ARM] Add new feature to enable optimizing the VFP registersEvandro Menezes2018-07-204-18/+25
| | | | | | | | | Enable the optimization of operations on DPR and SPR via a feature instead of checking the target. Differential revision: https://reviews.llvm.org/D49463 llvm-svn: 337575
* Add llvm::Any.Zachary Turner2018-07-204-0/+333
| | | | | | | | This is analogous to std::any which is only available in C++17. Differential Revision: https://reviews.llvm.org/D48807 llvm-svn: 337573
* Rewrite the VS integration scripts.Zachary Turner2018-07-2025-365/+590
| | | | | | | | | | | | | | | | | | | | | | | This is a new modernized VS integration installer. It adds a Visual Studio .sln file which, when built, outputs a VSIX that can be used to install ourselves as a "real" Visual Studio Extension. We can even upload this extension to the visual studio marketplace. This fixes a longstanding problem where we didn't support installing into VS 2017 and higher. In addition to supporting VS 2017, due to the way this is written we now longer need to do anything special to support future versions of VS as well. Everything should "just work". This also fixes several bugs with our old integration, such as MSBuild triggering full rebuilds when /Zi was used. Finally, we add a new UI page called "LLVM" which becomes visible when the LLVM toolchain is selected. For now this only contains one option which is the path to clang-cl.exe, but in the future we can add more things here. Differential Revision: https://reviews.llvm.org/D42762 llvm-svn: 337572
* [MSan] run materializeChecks() before materializeStores()Alexander Potapenko2018-07-202-7/+9
| | | | | | | | | | | | | | | | | | When pointer checking is enabled, it's important that every pointer is checked before its value is used. For stores MSan used to generate code that calculates shadow/origin addresses from a pointer before checking it. For userspace this isn't a problem, because the shadow calculation code is quite simple and compiler is able to move it after the check on -O2. But for KMSAN getShadowOriginPtr() creates a runtime call, so we want the check to be performed strictly before that call. Swapping materializeChecks() and materializeStores() resolves the issue: both functions insert code before the given IR location, so the new insertion order guarantees that the code calculating shadow address is between the address check and the memory access. llvm-svn: 337571
* [X86][SSE] Use SplitOpsAndApply to improve HADD/HSUB loweringSimon Pilgrim2018-07-205-72/+51
| | | | | | Improve AVX1 256-bit vector HADD/HSUB matching by using SplitOpsAndApply to split into 128-bit instructions. llvm-svn: 337568
* [llvm-objcopy, tests] Fix several llvm-objcopy testsStella Stamenova2018-07-201-1/+9
| | | | | | | | | | | | | | Summary: In Python 3, sys.stdout.write expects a string rather than bytes. In order to be able to write the bytes to stdout, we need to use the buffer directly instead. This change is borrowing the implementation for writing to stdout that cat.py uses. Note that we cannot use cat.py directly because the file we are trying to open is a gzip file. Reviewers: asmith, bkramer, alexshap, jakehehrlich Reviewed By: alexshap, jakehehrlich Subscribers: jakehehrlich, llvm-commits Differential Revision: https://reviews.llvm.org/D49515 llvm-svn: 337567
* [X86][AVX] Add support for i16 256-bit vector horizontal op redundant ↵Simon Pilgrim2018-07-202-3/+3
| | | | | | shuffle removal llvm-svn: 337566
* [X86][AVX] Add v16i16 horizontal op redundant shuffle testsSimon Pilgrim2018-07-201-0/+127
| | | | llvm-svn: 337565
* Fix build breakage from r337562Pavel Labath2018-07-201-3/+3
| | | | | | | I changed a variable's type from pointer to reference, but forgot to update the assert-only code. llvm-svn: 337564
* [DAG] Avoid Node Update assertion due to AND simplificationNirav Dave2018-07-202-3/+69
| | | | | | | | | | | | | | | | | Check for construction-time folding for incomplete AND nodes in BackwardsPropagateMask. Fixes PR38185. Reviewers: RKSimon, samparker Reviewed By: samparker Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D49444 llvm-svn: 337563
* DwarfDebug: Reduce duplication in addAccel*** methodsPavel Labath2018-07-204-51/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Each of the four methods had a dozen lines and was doing almost exactly the same thing: get the appropriate accelerator table kind and insert an entry into it. I move this common logic to a helper function and make these methods delegate to it. This came up in the context of D49493, where I've needed to make adding a string to a string pool slightly more complicated, and it seemed to make sense to do it in one place instead of five. To make this work I've needed to unify the interface of the AccelTable data types, as some used to store DIE& and others DIE*. I chose to unify to a reference as that's what the caller uses. This technically isn't NFC, because it changes the StringPool used for apple tables in the DWO case (now it uses the main file like DWARF v5 instead of the DWO file). However, that shouldn't matter, as DWO is not a thing on apple targets (clang frontend simply ignores -gsplit-dwarf). Reviewers: JDevlieghere, aprantl, probinson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49542 llvm-svn: 337562
* [X86][AVX] Add support for 32/64 bits 256-bit vector horizontal op redundant ↵Simon Pilgrim2018-07-202-11/+11
| | | | | | shuffle removal llvm-svn: 337561
* [DAG] Fix Memory ordering check in ReduceLoadOpStore.Nirav Dave2018-07-202-25/+20
| | | | | | | | | | | | | | | | | | When merging through a TokenFactor we need to check that the load may be ordered such that no other aliasing memory operations may happen. It is not sufficient to just check that the load is a member of the chain token factor as it there may be a indirect chain. Require the load's chain has only one use. This fixes PR37826. Reviewers: spatel, davide, efriedma, craig.topper, RKSimon Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D49388 llvm-svn: 337560
* [analyzer] Rename DanglingInternalBufferChecker to InnerPointerChecker.Reka Kovacs2018-07-206-41/+39
| | | | | | Differential Revision: https://reviews.llvm.org/D49553 llvm-svn: 337559
* [X86][AVX] Add 256-bit vector horizontal op redundant shuffle testsSimon Pilgrim2018-07-201-1/+260
| | | | llvm-svn: 337558
* [scudo] Simplify internal names (NFC)Kostya Kortchinsky2018-07-205-56/+51
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: There is currently too much redundancy in the class/variable/* names in Scudo: - we are in the namespace `__scudo`, so there is no point in having something named `ScudoX` to end up with a final name of `__scudo::ScudoX`; - there are a lot of types/* that have `Allocator` in the name, given that Scudo is an allocator I figure this doubles up as well. So change a bunch of the Scudo names to make them shorter, less redundant, and overall simpler. They should still be pretty self explaining (or at least it looks so to me). The TSD part will be done in another CL (eg `__scudo::ScudoTSD`). Reviewers: alekseyshl, eugenis Reviewed By: alekseyshl Subscribers: delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D49505 llvm-svn: 337557
* [www] Add CodeCompass and CodeChecker to Clang Related Projects pageBruno Cardoso Lopes2018-07-201-0/+22
| | | | llvm-svn: 337555
* [IPSCCP] Fix for bot failure caused by r337548Florian Hahn2018-07-201-1/+1
| | | | llvm-svn: 337554
* Implement cpu_dispatch/cpu_specific MultiversioningErich Keane2018-07-2027-222/+1317
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is an ICC feature that provides for function multiversioning. This feature is implemented with two attributes: First, cpu_specific, which specifies the individual function versions. Second, cpu_dispatch, which specifies the location of the resolver function and the list of resolvable functions. This is valuable since it provides a mechanism where the resolver's TU can be specified in one location, and the individual implementions each in their own translation units. The goal of this patch is to be source-compatible with ICC, so this implementation diverges from the ICC implementation in a few ways: 1- Linux x86/64 only: This implementation uses ifuncs in order to properly dispatch functions. This is is a valuable performance benefit over the ICC implementation. A future patch will be provided to enable this feature on Windows, but it will obviously more closely fit ICC's implementation. 2- CPU Identification functions: ICC uses a set of custom functions to identify the feature list of the host processor. This patch uses the cpu_supports functionality in order to better align with 'target' multiversioning. 1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function marked cpu_dispatch be an empty definition. This patch supports that as well, however declarations are also permitted, since the linker will solve the issue of multiple emissions. Differential Revision: https://reviews.llvm.org/D47474 llvm-svn: 337552
* Regenerate partial vector fold test. NFCI.Simon Pilgrim2018-07-201-4/+18
| | | | llvm-svn: 337551
* esan: fix shadow setupDmitry Vyukov2018-07-201-3/+3
| | | | | | | | | | r337531 changed return type of MmapFixedNoReserve, but esan wasn't updated. As the result esan shadow setup always fails. We probably need to make MmapFixedNoAccess signature consistent with MmapFixedNoReserve. But this is just to unbreak tests. llvm-svn: 337550
* [NFC][testcases] fold sdiv if two operands are negated and non-overflowChen Zheng2018-07-201-0/+147
| | | | llvm-svn: 337549
* Recommit r328307: [IPSCCP] Use constant range information for comparisons of ↵Florian Hahn2018-07-202-123/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | parameters. This version contains a fix to add values for which the state in ParamState change to the worklist if the state in ValueState did not change. To avoid adding the same value multiple times, mergeInValue returns true, if it added the value to the worklist. The value is added to the worklist depending on its state in ValueState. Original message: For comparisons with parameters, we can use the ParamState lattice elements which also provide constant range information. This improves the code for PR33253 further and gets us closer to use ValueLatticeElement for all values. Also, as we are using the range information in the solver directly, we do not need tryToReplaceWithConstantRange afterwards anymore. Reviewers: dberlin, mssimpso, davide, efriedma Reviewed By: mssimpso Differential Revision: https://reviews.llvm.org/D43762 llvm-svn: 337548
* [X86][AVX] Convert X86ISD::VBROADCAST demanded elts combine to use ↵Simon Pilgrim2018-07-202-17/+48
| | | | | | | | | | SimplifyDemandedVectorElts This is an early step towards using SimplifyDemandedVectorElts for target shuffle combining - this merely moves the existing X86ISD::VBROADCAST simplification code to use the SimplifyDemandedVectorElts mechanism. Adds X86TargetLowering::SimplifyDemandedVectorEltsForTargetNode to handle X86ISD::VBROADCAST - in time we can support all target shuffles (and other ops) here. llvm-svn: 337547
* Regenerate remainder test.Simon Pilgrim2018-07-201-25/+30
| | | | llvm-svn: 337546
* [InstSimplify] fold srem instruction if its two operands are negated.Chen Zheng2018-07-202-25/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D49423 llvm-svn: 337545
OpenPOWER on IntegriCloud