- Nov 05, 2019
-
-
Pavel Labath authored
-
Pavel Labath authored
Summary: The permissions in a memory region have ternary states (yes, no, don't know), but the memory region command only prints in binary, treating "don't know" as "yes", which is particularly confusing as for instance the unwinder will treat an unknown value as "no". This patch makes is so that we distinguish all three states when printing the values, using "?" to indicate the lack of information. It is implemented via a special argument to the format provider for the OptionalBool enumeration. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D69106
-
Roman Lebedev authored
-
Roman Lebedev authored
Summary: That fold keeps growing and growing :( I think this may be one of the last pieces for it. Since D67677/D67725, the fold knowns the general form of the pattern - where some masking is needed: https://rise4fun.com/Alive/F5R https://rise4fun.com/Alive/gslRa But there is one more huge piece missing - if you are extracting some bits, it is not impossible that the origin is wider than the extraction, i.e. there may be a truncation. And we don't deal with that yet. But we can, and the generalization remains fully identical: https://rise4fun.com/Alive/Uar https://rise4fun.com/Alive/5SW After a preparatory cleanup i think the diff looks rather clean. One missing piece is that in some patterns (especially pat. b), `-1` only needs to be `-1` in final type, but that is for later.. https://bugs.llvm.org/show_bug.cgi?id=42563 Reviewers: spatel, nikic Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69125
-
Luís Marques authored
Summary: Introduces the `InstrInfo::areMemAccessesTriviallyDisjoint` hook. The test could check for instruction reorderings, but to avoid being brittle it just checks instruction dependencies. Reviewers: asb, lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D67046
-
Pavel Labath authored
Summary: Handling relocations was not needed when the loclists section was a DWO-only thing. But since DWARF5, it is possible to use it in regular objects too, and the standard permits embedding addresses into the section directly. These addresses need to be relocated in unlinked files. Reviewers: JDevlieghere, dblaikie, probinson Subscribers: aprantl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68271
-
Simon Atanasyan authored
-
Simon Atanasyan authored
-
Sjoerd Meijer authored
With a few things fixed: - initialisaiton of the optimisation remark pass (this was causing the buildbot failures on PPC), - a test case. Differential Revision: https://reviews.llvm.org/D69660
-
David Green authored
-
Raphael Isemann authored
-
aqjune authored
-
Craig Topper authored
[X86] Lower the cost of avx512 horizontal bool and/or reductions to 2*log2(bitwidth)+1 for legal types. This better represents the kshift+binop we'd get for each stage before the final extract. Its likely we'll do even better by doing a kmov and a cmp with a GPR, but this is a good start. The default handling was costing a worst case single source permute shuffle of the vector before the binop. This worst case assumes the shuffle might have to be emulated with extracts and inserts. But since we know we're doing a reduction we can assume we'll get kshift lowering. There's still some room for improvement here, but this is much better than it was.
-
aqjune authored
Summary: - Define Instruction::Freeze, let it be UnaryOperator - Add support for freeze to LLLexer/LLParser/BitcodeReader/BitcodeWriter The format is `%x = freeze <ty> %v` - Add support for freeze instruction to llvm-c interface. - Add m_Freeze in PatternMatch. - Erase freeze when lowering IR to SelDag. Reviewers: deadalnix, hfinkel, efriedma, lebedev.ri, nlopes, jdoerfert, regehr, filcab, delcypher, whitequark Reviewed By: lebedev.ri, jdoerfert Subscribers: jfb, kristof.beyls, hiraditya, lebedev.ri, steven_wu, dexonsmith, xbolva00, delcypher, spatel, regehr, trentxintong, vsk, filcab, nlopes, mehdi_amini, deadalnix, llvm-commits Differential Revision: https://reviews.llvm.org/D29011
-
Yonghong Song authored
Commit fff27212 ("[BPF] Fix CO-RE bugs with bitfields") fixed CO-RE handling bitfield issues. But the implementation introduced a use after free bug. The "Base" of the intrinsic might be freed so later on accessing the Type of "Base" might access the freed memory. The failed test case, CodeGen/BPF/CORE/offset-reloc-middle-chain.ll is exactly used to test such a case. Similarly to previous attempt to remember Metadata etc, remember "Base" pointee Alignment in advance to avoid such use after free bug.
-
Craig Topper authored
[X86] Teach X86MCInstLower to swap operands of commutable instructions to enable 2-byte VEX encoding. Summary: The 2 source operands commutable instructions are encoded in the VEX.VVVV field and the r/m field of the MODRM byte plus the VEX.B field. The VEX.B field is missing from the 2-byte VEX encoding. If the VEX.VVVV source is 0-7 and the other register is 8-15 we can swap them to avoid needing the VEX.B field. This works as long as the VEX.W, VEX.mmmmm, and VEX.X fields are also not needed. Fixes PR36706. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68550
-
Devin Coughlin authored
Let's at least get some coverage from these tests. We can generalize to other platforms later.
-
Devin Coughlin authored
This is a fix to 0aba69eb to address failing bots.
-
aqjune authored
Summary: This patch resolves llvm-c-test's following error ``` LLVM ERROR: LLVMGetValueKind returned incorrect type ``` which arises when the input bitcode contains a null pointer. Reviewers: jdoerfert, CodaFi, deadalnix Reviewed By: jdoerfert Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68928
-
Devin Coughlin authored
The static analyzer's scan-build script is critical infrastructure but is not well tested. To start to address this, add a new test directory under tests/Analysis for scan-build lit tests and seed it with several tests. The goal is that future scan-build changes will be accompanied by corresponding tests. Differential Revision: https://reviews.llvm.org/D69781
-
Yaxun (Sam) Liu authored
The linker options (e.g. pragma detect_mismatch) are intended for host compilation only, therefore disable it for device compilation. Differential Revision: https://reviews.llvm.org/D57829
-
Yonghong Song authored
bitfield handling is not robust with current implementation. I have seen two issues as described below. Issue 1: struct s { long long f1; char f2; char b1:1; } *p; The current approach will generate an access bit size 56 (from b1 to the end of structure) which will be rejected as it is not power of 2. Issue 2: struct s { char f1; char b1:3; char b2:5; char b3:6: char b4:2; char f2; }; The LLVM will group 4 bitfields together with 2 bytes. But loading 2 bytes is not correct as it violates alignment requirement. Note that sometimes, LLVM breaks a large bitfield groups into multiple groups, but not in this case. To resolve the above two issues, this patch takes a different approach. The alignment for the structure is used to construct the offset of the bitfield access. The bitfield incurred memory access is an aligned memory access with alignment/size equal to the alignment of the structure. This also simplified the code. This may not be the optimal memory access in terms of memory access width. But this should be okay since extracting the bitfield value will have the same amount of work regardless of what kind of memory access width. Differential Revision: https://reviews.llvm.org/D69837 -
Jorg Brown authored
Same idea as the current algorithm, that is, add (half of the difference between a and b) to a. But we use a different technique for computing the difference: we compute b - a into a pair of integers that are named "sign_bit" and "diff". We have to use a pair because subtracting two 32-bit integers produces a 33-bit result. Computing half of that is a simple matter of shifting diff right by 1, and adding sign_bit shifted left by 31. llvm knows how to do that with one instruction: shld. The only tricky part is that if the difference is odd and negative, then shifting it by one isn't the same as dividing it by two - shifting a negative one produces a negative one, for example. So there's one more adjustment: if the sign bit and the low bit of diff are one, we add one. For a demonstration of the codegen difference, see https://godbolt.org/z/7ar3K9 , which also has a built-in test. Differential Revision: https://reviews.llvm.org/D69459
-
Vedant Kumar authored
The swift build system has support for cross-compiling, installing, and generating symbols for lldb. As the swift symbol-generation step occurs after installation, we need to disable stripping during the install.
-
Saleem Abdulrasool authored
The unwinder should not depend on libc++. In fact, we do not end up with a link against libc++ as we do not have a dependency on libc++ at runtime. This ensures that we link with `clang` rather than `clang++`.
-
Vedant Kumar authored
Currently, clang emits subprograms for declared functions when the target debugger or DWARF standard is known to support entry values (DW_OP_entry_value & the GNU equivalent). Treat DW_AT_tail_call the same way to allow debuggers to follow cross-TU tail calls. Pre-patch debug session with a cross-TU tail call: ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` Post-patch (note that the tail-calling frame, "helper", is visible): ``` * frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt] frame #1: 0x0000000100000f80 main`helper [opt] [artificial] frame #2: 0x0000000100000f99 main`main at a.c:8:10 [opt] ``` rdar://46577651 Differential Revision: https://reviews.llvm.org/D69743 -
Ron Lieberman authored
-
Evandro Menezes authored
Fix the costs of integer division.
-
Sam Clegg authored
Also add the aliases for these tools so that LLVM_INSTALL_BINUTILS_SYMLINKS and LLVM_INSTALL_TOOLCHAIN_ONLY can work together. Differential Revision: https://reviews.llvm.org/D69635
-
Mark de Wever authored
Also a test for commit access.
-
Stanislav Mekhanoshin authored
-
Alexey Bataev authored
-
James Y Knight authored
(Which was "[ObjC] Diagnose implicit type coercion from ObjC 'Class' to object pointer types.")
-
Alexey Bataev authored
Added support for imperfectly nested loops introduced in OpenMP 5.0.
-
Lawrence D'Anna authored
Summary: This patch updates the last user of ArgInfo::count and deletes it. I also delete `GetNumInitArguments()` and `GetInitArgInfo()`. Classess are callables and `GetArgInfo()` should work on them. On python 3 it already works, of course. `inspect` is good. On python 2 we have to add yet another special case. But hey if python 2 wasn't crufty we wouln't need python 3. I also delete `is_bound_method` becuase it is unused. This path is tested in `TestStepScripted.py` Reviewers: labath, mgorny, JDevlieghere Reviewed By: labath, JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69742
-
Stanislav Mekhanoshin authored
We are duplicating predicates if several parts of the combined predicate list contain the same condition. Added code to deduplicate the list. We have AssemblerPredicates and AssemblerPredicate in the PredicateControl, but we never use AssemblerPredicates with an actual list, so this one is dropped. This addresses the first part of the llvm bug 43886: https://bugs.llvm.org/show_bug.cgi?id=43886 Differential Revision: https://reviews.llvm.org/D69815
-
Erik Pilkington authored
This class was a bit overengineered, and was triggering some PVS warnings. Instead, put strings into a NameType and let clients unconditionally treat it as a Node.
-
Alexandre Ganea authored
Fixes warning: unused variable 'XXX' [-Wunused-const-variable]
-
Alexandre Ganea authored
Fix warning: format specifies type 'unsigned long' but the argument has type 'unsigned long long' [-Wformat]
-
Duncan P. N. Exon Smith authored
31e14f41 accidentally dropped caching of failed module loads. This brings it back by making ModuleMap::getCachedModuleLoad return an Optional.
-