- Jul 21, 2018
-
-
H.J. Lu authored
When shadow stack from Intel CET is enabled, the first instruction of all indirect branch targets must be a special instruction, ENDBR. lib/asan/asan_interceptors.cc has ... int res = REAL(swapcontext)(oucp, ucp); ... REAL(swapcontext) is a function pointer to swapcontext in libc. Since swapcontext may return via indirect branch on x86 when shadow stack is enabled, as in this case, int res = REAL(swapcontext)(oucp, ucp); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This function may be returned via an indirect branch. Here compiler must insert ENDBR after call, like call *bar(%rip) endbr64 I opened an LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=38207 to add the indirect_return attribute so that it can be used to inform compiler to insert ENDBR after REAL(swapcontext) call. We mark REAL(swapcontext) with the indirect_return attribute if it is available. This fixed: https://bugs.llvm.org/show_bug.cgi?id=38249 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D49608 llvm-svn: 337603 -
Julie Hockett authored
Submitted on behalf of Annie Cherkaev (@anniecherk) Added a flag which, when enabled, documents only those methods and fields which have a Public attribute. Differential Revision: https://reviews.llvm.org/D48395 llvm-svn: 337602
-
Benjamin Kramer authored
This only shows up with asan when the stars align in a bad way. llvm-svn: 337601
-
Reid Kleckner authored
llvm-svn: 337600
-
Martin Storsjo authored
llvm-svn: 337599
-
Martin Storsjo authored
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
-
Reid Kleckner authored
llvm-svn: 337597
-
Zachary Turner authored
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
-
Lang Hames authored
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
-
Lang Hames authored
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
-
Lang Hames authored
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
-
Benjamin Kramer authored
-Winconsistent-missing-override complains about this. llvm-svn: 337592
-
Zachary Turner authored
Also remove a broken test case. llvm-svn: 337591
-
Craig Topper authored
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
-
Craig Topper authored
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
-
Zachary Turner authored
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
-
Artem Belevich authored
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
-
Simon Pilgrim authored
llvm-svn: 337586
-
Erich Keane authored
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
-
Zachary Turner authored
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
-
Philip Pfaffe authored
llvm-svn: 337583
-
Zachary Turner authored
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
-
Alina Sbirlea authored
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
-
Akira Hatanaka authored
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
-
Dan Liew authored
`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
-
Simon Pilgrim authored
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
-
Alexander Potapenko authored
Make sure NewSI is used in materializeStores() llvm-svn: 337577
-
Zachary Turner authored
bool_constant is C++17. llvm-svn: 337576
-
Evandro Menezes authored
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
-
Zachary Turner authored
This is analogous to std::any which is only available in C++17. Differential Revision: https://reviews.llvm.org/D48807 llvm-svn: 337573
-
Zachary Turner authored
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
-
Alexander Potapenko authored
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
-
Simon Pilgrim authored
Improve AVX1 256-bit vector HADD/HSUB matching by using SplitOpsAndApply to split into 128-bit instructions. llvm-svn: 337568
-
Stella Stamenova authored
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
-
- Jul 20, 2018
-
-
Simon Pilgrim authored
llvm-svn: 337566
-
Simon Pilgrim authored
llvm-svn: 337565
-
Pavel Labath authored
I changed a variable's type from pointer to reference, but forgot to update the assert-only code. llvm-svn: 337564
-
Nirav Dave authored
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
-
Pavel Labath authored
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
-
Simon Pilgrim authored
llvm-svn: 337561
-