- Nov 30, 2020
-
-
Sanjay Patel authored
https://llvm.org/PR48296 shows an example where we delete all of the operands of a phi without actually deleting the phi, and that is currently considered invalid IR. The reduced test included here would crash for that reason. A suggested follow-up is to loosen the assert to allow 0-operand phis in unreachable blocks. Differential Revision: https://reviews.llvm.org/D92247
-
Dmitri Gribenko authored
'-debug-only=machine-scheduler' only works when asserts are enabled.
-
Pedro Tammela authored
These callbacks are set using the following: breakpoint command add -s lua -o "print('hello world!')" The user supplied script is executed as: function (frame, bp_loc, ...) <body> end So the local variables 'frame', 'bp_loc' and vararg are all accessible. Any global variables declared will persist in the Lua interpreter. A user should never hold 'frame' and 'bp_loc' in a global variable as these userdatas are context dependent. Differential Revision: https://reviews.llvm.org/D91508 -
Juneyoung Lee authored
-
Juneyoung Lee authored
.. because it causes miscompilation when combined with select i1 -> and/or. It is the select fold which is incorrect; but it is costly to disable the fold, so hack this one. D92270
-
David Spickett authored
This fixes test failure on clang-cmake-armv7-quick bot with change c2ead57c. This bot only builds Arm/AArch64 targets.
-
Simon Pilgrim authored
-
Nico Weber authored
This adds support for ld.lld's --reproduce / lld-link's /reproduce: flag to the MachO port. This flag can be added to a link command to make the link write a tar file containing all inputs to the link and a response file containing the link command. This can be used to reproduce the link on another machine, which is useful for sharing bug report inputs or performance test loads. Since the linker is usually called through the clang driver and adding linker flags can be a bit cumbersome, setting the env var `LLD_REPRODUCE=foo.tar` triggers the feature as well. The file response.txt in the archive can be used with `ld64.lld.darwinnew $(cat response.txt)` as long as the contents are smaller than the command-line limit, or with `ld64.lld.darwinnew @response.txt` once D92149 is in. The support in this patch is sufficient to create a tar file for Chromium's base_unittests that can link after unpacking on a different machine. Differential Revision: https://reviews.llvm.org/D92274
-
Hans Wennborg authored
-
Nico Weber authored
ld64 learned about them in Xcode 12, so we should too. Differential Revision: https://reviews.llvm.org/D92149
-
Kazushi (Jam) Marukawa authored
Optimize eliminate FP mechanism. This time optimize a function which has no call but fixed stack objects. LLVM eliminates FP on such functions now. Also, optimize GOT/PLT registers save/restore instructions if a given function doesn't uses them. In addition, remove generating mechanism of `.cfi` instructions since those are taken from other architectures and not inspected yet. Update regression tests, also. Reviewed By: simoll Differential Revision: https://reviews.llvm.org/D92251
-
Hans Wennborg authored
-
Kazushi (Jam) Marukawa authored
Change the way to truncate i64 to i32 in I64 registers. VE assumed sext values previously. Change it to zext values this time to make it match to the LLVM behaviour. Reviewed By: simoll Differential Revision: https://reviews.llvm.org/D92226
-
Florian Hahn authored
VPPredInstPHIRecipe is one of the recipes that was missed during the initial conversion. This patch adjusts the recipe to also manage its operand using VPUser.
-
Kazushi (Jam) Marukawa authored
Specify alignments for all vector types. Update a regression test also. Reviewed By: simoll Differential Revision: https://reviews.llvm.org/D92256
-
David Spickett authored
This does the same as `--mcpu=help` but was only documented in the user guide. * Added a test for both options. * Corrected the single dash in `-mcpu=help` text. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D92305
-
Hans Wennborg authored
This adds the clang-tidy concurrency module to the gn build.
-
Muhammad Omair Javaid authored
This patch ovverides GetExpeditedRegisterSet for NativeRegisterContextLinux_arm64 to send vector granule register in expedited register set if SVE mode is selected. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D82855
-
Muhammad Omair Javaid authored
This patch adds capability to introduce a custom expedited register set in gdb remote. Currently we send register set 0 as expedited register set but for the case of AArch64 SVE we intend to send additional information about SVE registers size/offset configuration which can be calculated from vg register. Therefore we will expedited Vg register in case of AArch64 is in SVE mode to speedup register configuration calculations. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D82853
-
Sjoerd Meijer authored
This was modeled to have a cost of 1, but since we do not have a MUL.2d this is scalarized into vector inserts/extracts and scalar muls. Motivating precommitted test is test/Transforms/SLPVectorizer/AArch64/mul.ll, which we don't want to SLP vectorize. Test Transforms/LoopVectorize/AArch64/extractvalue-no-scalarization-required.ll unfortunately needed changing, but the reason is documented in LoopVectorize.cpp:6855: // The cost of executing VF copies of the scalar instruction. This opcode // is unknown. Assume that it is the same as 'mul'. which I will address next as a follow up of this. Differential Revision: https://reviews.llvm.org/D92208
-
David Spickett authored
Previously we used UINT16_MAX to mean no port/no specifc port. This leads to confusion because 65535 is a valid port number. Instead use an optional. If you want a specific port call LaunchGDBServer as normal, otherwise pass an empty optional and it will be set to the port that gets chosen. (or left empty in the case where we fail to find a port) Reviewed By: labath Differential Revision: https://reviews.llvm.org/D92035
-
Simon Pilgrim authored
-
Christian Sigg authored
Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D92303
-
Jay Foad authored
-
Roman Lebedev authored
It seems that while clangASTMatchers does add FrontendOpenMP into it's LLVM_LINK_COMPONENTS, it's still not being propagated transitively.
-
David Spickett authored
Previously if you did: $ lldb-server platform --server <...> --min-gdbserver-port 12346 --max-gdbserver-port 12347 (meaning only use port 12346 for gdbservers) Then tried to launch two gdbservers on the same connection, the second one would return port 65535. Which is a real port number but it actually means lldb-server didn't find one it was allowed to use. send packet: $qLaunchGDBServer;<...> read packet: $pid:1919;port:12346;#c0 <...> send packet: $qLaunchGDBServer;<...> read packet: $pid:1927;port:65535;#c7 This situation should be an error even if port 65535 does happen to be available on the current machine. To fix this make PortMap it's own class within GDBRemoteCommunicationServerPlatform. This almost the same as the old typedef but for GetNextAvailablePort() returning an llvm::Expected. This means we have to handle not finding a port, by returning an error packet. Also add unit tests for this new PortMap class. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D91634
-
David Spickett authored
At least with git, file paths in a diff will be relative to the repo root. So if you are in "llvm-project/lldb" and the diff shows "clang/foo" modified you get: No such file or directory From clang-format-diff.py, since clang-format was asked to read: llvm-project/lldb/clang/foo Add a note to the docs to explain this. (there is `git diff --relative` but that excludes changes outside of the current dir) Reviewed By: sylvestre.ledru Differential Revision: https://reviews.llvm.org/D91799
-
Evgeny Leviant authored
-
Vasily Kulikov authored
Checks for some thread-unsafe functions against a black list of known-to-be-unsafe functions. Usually they access static variables without synchronization (e.g. gmtime(3)) or utilize signals in a racy way (e.g. sleep(3)). The patch adds a check instead of auto-fix as thread-safe alternatives usually have API with an additional argument (e.g. gmtime(3) v.s. gmtime_r(3)) or have a different semantics (e.g. exit(3) v.s. __exit(3)), so it is a rather tricky or non-expected fix. An option specifies which functions in libc should be considered thread-safe, possible values are `posix`, `glibc`, or `any` (the most strict check). It defaults to 'any' as it is unknown what target libc type is - clang-tidy may be run on linux but check sources compiled for other *NIX. The check is used in Yandex Taxi backend and has caught many unpleasant bugs. A similar patch for coroutine-unsafe API is coming next. Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D90944
-
Vasily Kulikov authored
The module will contain checks related to concurrent programming (including threads, fibers, coroutines, etc.). Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D91656
-
Roman Lebedev authored
-
David Green authored
-
Evgeny Leviant authored
Patch fixes multiple issues related to expansion of variant sched reads and writes. Differential revision: https://reviews.llvm.org/D90844
-
Nicolas Vasilache authored
The InlineAsmOp mirrors the underlying LLVM semantics with a notable exception: the embedded `asm_string` is not allowed to define or reference any symbol or any global variable: only the operands of the op may be read, written, or referenced. Attempting to define or reference any symbol or any global behavior is considered undefined behavior at this time. The asm dialect syntax is currently specified with an integer (0 [default] for the "att dialect", 1 for the intel dialect) to circumvent the ODS limitation on string enums. Translation to LLVM is provided and raises the fact that the asm constraints string must be well-formed with respect to in/out operands. No check is performed on the asm_string. An InlineAsm instruction in LLVM is a special call operation to a function that is constructed on the fly. It does not fit the current model of MLIR calls with symbols. As a consequence, the current implementation constructs the function type in ModuleTranslation.cpp. This should be refactored in the future. The mlir-cpu-runner is augmented with the global initialization of the X86 asm parser to allow proper execution in JIT mode. Previously, only the X86 asm printer was initialized. Differential revision: https://reviews.llvm.org/D92166
-
Haojian Wu authored
suppress the diagnostics for missing return stmt in constexpr func. Differential Revision: https://reviews.llvm.org/D82284
-
Guillaume Chatelet authored
Rewriting loop so the terminating condition does not depend on the loop body Differential Revision: https://reviews.llvm.org/D91976
-
Haojian Wu authored
Given the following case: ``` auto k() { return undef(); return 1; } ``` Prior to the patch, clang emits an `cannot initialize return object of type 'auto' with an rvalue of type 'int'` diagnostic on the second return (because the return type of the function cannot be deduced from the first contain-errors return). This patch suppresses this error. Differential Revision: https://reviews.llvm.org/D92211 -
Pavel Labath authored
A separate thread is not necessary, as we can do its work on the main thread, while waiting for the packet to arrive. This makes the code easier to understand and debug (other simplifications are possible too, but I'll leave that for separate patches). The new implementation also avoids busy waiting.
-
Stella Laurenzo authored
* Follows on https://reviews.llvm.org/D92193 * I had a mid-air collision with some additional occurrences and then noticed that there were a lot more. Think I got them all. Differential Revision: https://reviews.llvm.org/D92292
-
Max Kazantsev authored
If we decided to widen IV with zext, then unsigned comparisons should not prevent widening (same for sext/sign comparisons). The result of comparison in wider type does not change in this case. Differential Revision: https://reviews.llvm.org/D92207 Reviewed By: nikic
-