- Jun 21, 2022
-
-
https://reviews.llvm.org/D127702Jeffrey Tan authored
Fix build break introduced by https://reviews.llvm.org/D127702 Differential Revision: https://reviews.llvm.org/D128234
-
archsaxe authored
This fixes a useless filecheck and wrong comment for always-inline.ll. Testing has been done using ninja check-llvm and llvm-lit always-inline.ll --show-all. Reviewed By: modimo, hoy Differential Revision: https://reviews.llvm.org/D127815
-
Pengxuan Zheng authored
Microsoft does not seem to document the flag. Ignoring it for now is probably better than getting an unknown flag error. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D128231
-
lewuathe authored
Lower math.cos and math.sin to libm Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D128028
-
Jeffrey Tan authored
This patch implements VSCode DAP logpoints feature (also called tracepoint in other VS debugger). This will provide a convenient way for user to do printf style logging debugging without pausing debuggee. Differential Revision: https://reviews.llvm.org/D127702
-
Nico Weber authored
This reverts commit cd7624f1. See https://reviews.llvm.org/D128184#3597534
-
Daniel Bertalan authored
The error used to look like this: ld64.lld: error: undefined symbol: _foo >>> referenced by /path/to/bar.o:(symbol _baz+0x4) If DWARF line information is available, we now show where in the source the references are coming from: ld64.lld: error: unreferenced symbol: _foo >>> referenced by: bar.cpp:42 (/path/to/bar.cpp:42) >>> /path/to/bar.o:(symbol _baz+0x4) Differential Revision: https://reviews.llvm.org/D128184
-
Kazushi (Jam) Marukawa authored
Add missing intrinsics and tests for them. An expanding macro from _vel_pack_f32p to __builtin_ve_vl_pack_f32p and others is already defined in clang/lib/Headers/velintrin.h. Reviewed By: efocht Differential Revision: https://reviews.llvm.org/D128120
-
Maksim Panchenko authored
Misaligned stack can cause a runtime crash. Reviewed By: Amir Differential Revision: https://reviews.llvm.org/D128227
-
Martin Storsjö authored
-
Ruiling Song authored
The instructions that generate the source of dual source blend export should run in strict-wqm. That is if any lane in a quad is active, we need to enable all four lanes of that quad to make the shuffling operation before exporting to dual source blend target work correctly. Differential Revision: https://reviews.llvm.org/D127981
-
Piotr Sobczak authored
LDS_PARAM_LOAD and LDS_DIRECT_LOAD use EXEC per quad (if any pixel is enabled in the quad, data is written to all 4 pixels/threads in the quad). Tag LDS_PARAM_LOAD and LDS_DIRECT_LOAD as using strict_wqm to enforce this and avoid lane clobbering issues. Note that only the instruction itself is tagged. The implicit uses of these do not need to be set WQM. The reduces unnecessary WQM calculation of M0. Differential Revision: https://reviews.llvm.org/D127977
-
Jay Foad authored
Detect LDS direct WAR/WAW hazards and compute values for wait_vdst (va_vdst) parameter. Where appropriate this raises wait_vdst from the default 0 to allow concurrent issue of LDS direct with VALU execution. Also detect LDS direct versus VMEM source VGPR hazards and insert vm_vsrc=0 waits using s_waitcnt_depctr. Differential Revision: https://reviews.llvm.org/D127963
-
Philip Reames authored
If we would scalarize a fixed vector, we know we can't do so for a scalable one. However, there's no need to crash, we can instead simply return a invalid cost which will work its way through the computation (since invalid is sticky), and the client should bail out. Sorry for the lack of test here. The particular codepath I saw this reached on was the result of another bug.
-
Amir Ayupov authored
Make Offsets and OpcodeOperandTypes tables human-readable by printing the instruction name before the operand list. In effect, this makes debugging generated `getOperandType` possible. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D127931
-
Philip Reames authored
This was a bug introduced in d764aa. A pointer type is not a primitive type, and thus we were ending up dividing by zero when computing VLMax. Differential Revision: https://reviews.llvm.org/D128219
-
Mehdi Chinoune authored
This turns off a bunch of non-standard behaviors in MSVC. LLVM, as a portable codebase, should build correctly without those behaviors. Note that `/permissive-` implies `/Zc:strictStrings` and `/Zc:rvalueCast`. See also: https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance Differential Revision: https://reviews.llvm.org/D125263
-
Amir Ayupov authored
This reverts commit 4cd41619.
-
Florian Hahn authored
-
Nemanja Ivanovic authored
There are instances where using paired vector stores leads to significant performance degradation due to issues with store forwarding.To avoid falling into this trap with compiler - generated code, we will not emit these instructions unless the user requests them explicitly(with a builtin or by specifying the option). Reviewed By : lei, amyk, saghir Differential Revision: https://reviews.llvm.org/D127218
-
Amir Ayupov authored
Make Offsets and OpcodeOperandTypes tables human-readable by printing the instruction name before the operand list. In effect, this makes debugging generated `getOperandType` possible. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D127931
-
Jakob Johnson authored
Add trace load functionality to SBDebugger via the `LoadTraceFromFile` method. Update intelpt test case class to have `testTraceLoad` method so we can take advantage of the testApiAndSB decorator to test both the CLI and SB without duplicating code. Differential Revision: https://reviews.llvm.org/D128107
-
Kazu Hirata authored
-
Kazu Hirata authored
-
Kazu Hirata authored
-
David Green authored
An AArch64ISD::DUP is just a splat, where the known bits for each lane are the same as the input. This teaches that to computeKnownBitsForTargetNode. Problems arise for constants though, as a constant BUILD_VECTOR can be lowered to an AArch64ISD::DUP, which SimplifyDemandedBits would then turn back into a constant BUILD_VECTOR leading to an infinite cycle. This has been prevented by adding a isTargetCanonicalConstantNode node to prevent the conversion back into a BUILD_VECTOR. Differential Revision: https://reviews.llvm.org/D128144
-
Kazu Hirata authored
-
Simon Pilgrim authored
v32i8/v16i16 blend shuffles on AVX1 will expand to OR(AND,ANDN) patterns which can be easily broken by other combines
-
Michał Górny authored
Fix test_platform_file_fstat to correctly truncate/max out the expected value when GDB Remote Serial Protocol specifies a value as an unsigned integer but the underlying platform type uses a signed integer. Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.llvm.org/D128042
-
Michał Górny authored
Make the AVX/MPX register tests more robust by checking for the presence of actual registers rather than register sets. Account for the option that the respective registers are defined but not available, as is the case on FreeBSD and NetBSD. This fixes test regression on these platforms. Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.llvm.org/D128041
-
Michał Górny authored
The -gmodule tests currently fail on FreeBSD due to include bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264730 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.llvm.org/D128034
-
Michał Górny authored
Refactor GDBRemoteCommunicationServerLLGS::SendStopReasonForState() to accept process as an argument rather than hardcoding m_current_process, in order to make it work correctly for multiprocess scenarios. Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.llvm.org/D127497
-
Michał Górny authored
Refactor SendStopReplyPacketForThread() to accept process instance as a parameter rather than use m_current_process. This future-proofs it for multiprocess support. Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.llvm.org/D127289
-
Philip Reames authored
This change removes an explicit scalable vector bailout for fshl and fshr. This bailout was added in 60e4698b, when sinking a unconditional bailout for all intrinsics into selected cases. Its not clear if the bailout was originally unneeded, or if our cost model infrastructure has simply matured in the meantime. Either way, the generic code appears to handle scalable vectors without issue. Note that the RISC-V cost model changes here aren't particularly interesting. They do probably better match the current lowering, but the main point is to have coverage of the BasicTTI path and simply show lack of crashing. AArch64 costing was changed to preserve legacy behavior. There will most likely be an upcoming change to use the generic costs there too, but I didn't want to make that change not being particularly familiar with the target. Differential Revision: https://reviews.llvm.org/D127680
-
Kazu Hirata authored
-
Stanislav Gatev authored
Extend flow condition in the body of a do/while loop. Differential Revision: https://reviews.llvm.org/D128183 Reviewed-by: gribozavr2, xazax.hun
-
Arthur Eubanks authored
This reverts commit 6f348b14. Am seeing internal test failures plus a linux kernel breakage reported due to this.
-
Arthur Eubanks authored
This reverts commit cc65f3e1. Causes crashes: https://github.com/llvm/llvm-project/issues/56131
-
Philip Reames authored
The code being removed is technically correct; if we end up with two VL=0 instructions next to each other, we can avoid a state transition if the second is a scalar move. However, since both ops are also nops, we should simply delete them instead. As such, this compatibility rule simply complicates the code for no purpose.
-
- Jun 20, 2022
-
-
David Candler authored
Depending on the environment, a floating point instruction should treat denormal inputs as zero, and/or flush a denormal output to zero. Denormals are not currently accounted for when an instruction gets folded to a constant, which can lead to differences in output between a folded and a unfolded instruction when running on the target. The denormal handling mode can be set by the function level attribute denormal-fp-math, which this patch uses to determine whether any denormal inputs to or outputs from folding should be zero, and that the sign is set appropriately. Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D116952
-