#140210 added `#include "clang/Frontend/FrontendDiagnostic.h"` to
clang/lib/Sema/SemaAMDGPU.cpp, but Frontend itself has a dependency on
Sema. This creates a layering issue as described in
https://llvm.org/docs/CodingStandards.html#library-layering.
Fortunately, d076608d58 made this easy to
fix, as clang/Frontend/FrontendDiagnostic.h just forwards to
clang/Basic/DiagnosticFrontend.h, so it's trivial to make this depend on
basic instead of frontend.
This patch updates the FP-to-Int conversion handling:
- For signed integers: use `ftrunc` followed by clamping to the target
integer range.
- For unsigned integers: apply `fabs` + `ftrunc`, then clamp.
This removes the previous dependence on `nsz` and ensures correct
lowering for both signed and unsigned cases.
I've tested the code generation of -mtriple=amdgcn. It seems that the
assembly code is expected, but I'm not sure how to write a general
testcase for every target.
Fixes#160623.
ec28b95b74 made liblldb delayloaded, but
the supplied command line parameter is only valid for MSVC style builds.
For mingw builds using LLD, we can easily pass a similar option. For
mingw builds with ld.bfd, we can't quite as easily delayload it - for
these cases, just keep linking it like we usually do, and warn if the
user tried to set LLDB_PYTHON_DLL_RELATIVE_PATH in a build where it
won't have any effect.
Also change the setting for MSVC style builds, to use the simpler
`$<TARGET_FILE_NAME:liblldb>` instead of
`$<TARGET_FILE_BASE_NAME:liblldb>.dll`. The former pattern is what we
use for mingw targets, and it makes the code clearer to use that for
both, as that same expression should do the right thing for both.
Since 4feae05c6a, most of the handling of
warning options was rewritten to add such options based on hardcoded
knowledge about what compilers support which options, and since which
versions. This avoids a number of configure time checks, speeding up the
cmake configuration.
This avoids erroneously adding this option with GCC, which doesn't
really support it.
If testing for a warning option like -Wno-<foo> with GCC, GCC won't
print any diagnostic at all, leading to the options being accepted
incorrectly. However later, if compiling a file that actually prints
another warning, GCC will also print warnings about these -Wno-<foo>
options being unrecognized.
This avoids extra warning spam like this, for every source file that
does produce warnings with GCC:
At global scope:
cc1plus: note: unrecognized command-line option ‘-Wno-pass-failed’ may have been intended to silence earlier diagnostics
This fixes building LLDB for mingw with libstdc++, after
8ae30a3fac.
Previously, building errored out with errors like these:
In file included from llvm-project/lldb/include/lldb/Protocol/MCP/Transport.h:12,
from llvm-project/lldb/include/lldb/Protocol/MCP/Server.h:16,
from llvm-project/lldb/source/Plugins/Protocol/MCP/ProtocolServerMCP.h:15,
from llvm-project/lldb/source/Plugins/Protocol/MCP/ProtocolServerMCP.cpp:9:
llvm-project/lldb/include/lldb/Host/JSONTransport.h:608:23: error: field ‘replied’ has incomplete type ‘std::atomic<bool>’
608 | std::atomic<bool> replied = {false};
| ^~~~~~~
In file included from gcc-mingw/x86_64-w64-mingw32/include/c++/12.1.0/bits/shared_ptr_atomic.h:33,
from gcc-mingw/x86_64-w64-mingw32/include/c++/12.1.0/memory:78,
from llvm-project/lldb/include/lldb/Host/Socket.h:12,
from llvm-project/lldb/include/lldb/Core/ProtocolServer.h:13,
from llvm-project/lldb/source/Plugins/Protocol/MCP/ProtocolServerMCP.h:12:
gcc-mingw/x86_64-w64-mingw32/include/c++/12.1.0/bits/atomic_base.h:162:12: note: declaration of ‘struct std::atomic<bool>’
162 | struct atomic;
| ^~~~~~
I did this when I converted it but never stated so. Adding a comment
stating so. We'll probably forget at some point but might as well.
Also moved the x packet to the last place, after wasm which was
added to the end recently.
The uArch infrastructure provides:
- A set data structures to represent, uArch and it's necessary
components (e.g., instructions, register-files, caches).
- A set of utility interfaces that are common to a family of ops (e.g.,
mma ops, 2DBlockIO ops). The implementation of these interfaces are
provided by the specific instructions. Each family of ops provides these
5 common APIs. However, some family of ops may have more utility APIs.
The common 5 APIs are:
- getSupportedShapes
- getSupportedTypes
- checkSupportedShapesAndTypes
- checkSupportedTypes
- validate
Add support for PVC and BMG architectures.
Add support for DPAS instruction.
DW_OP_LLVM_extract_bits_zext and DW_OP_LLVM_extract_bits_sext can end up
emitting "DW_OP_constu 0; DW_OP_shr" when given certain arguments.
However, a shift by zero is not useful, and so it can be omitted.
This is unnecessary. At use emission time, InstrEmitter will
use the common subclass of the value type's register class and
the use instruction register classes. This removes one of the
obstacles to treating special case instructions that do not have
the alignment requirement overly conservatively.
Currently, LLDB in FreeBSD host sets the Process Architecture used by
lldbserver as Default one. Which cause problem when trying to debug a
32bit binary on amd64 platform since the lldb itself will found mismatch
architecture with lldbserver's return.
Notice that this patch is only a partial fix for the debugging problem.
We are still unable to debug x86 on x86_64 so that we don't provide
testcase in this patch.
See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289945
This is a follow-up PR for post-commit comments in #128782 .
- Fix variable name to camel case.
- Change the output format to make it easier to handle with FileCheck.
- Regenerate assertions of regression tests.
This patch starts to find terminator from `VarDecl`'s end location
rather than it's `getLocation()` to ignore terminator(`,`) in function
paramaters list.
Kind of follow up to #112091Closes#161978 .
The complexity of maintaining an extra kind of metrics have not
justified itself, as it is not used upstream, and we have only a single
use of boolean stats per entrypoint downstream.
As I will do downstream, you can use an unsigned statistic type with
values 0 and 1 to model a boolean flag.
--
CPP-7097
[AMDGPU][GlobalISel] Add register bank legalization for
G_SMIN/G_SMAX/G_UMIN/G_UMAX
This patch adds register bank legalization support for min/max
operations in the AMDGPU GlobalISel pipeline.
- Add support S16, S32, and V2S16 types
- For V2S16 uniform operations implements UnpackMinMax lowering
- Make instruction arguments to the `misexpect` functions const and drop
const for `ArrayRef` arguments.
- Remove namespace llvm/misexpect surrounding all the code in .cpp file
and instead use `using namespace`.
- Change static helper functions to also use const references or
pointers when possible.
Using SlotIndexes::getMBBEndIdx() isn't the correct choice here because
it returns the starting index of the next basic block, causing live-ins
of the next block to be calculated instead of the intended live-outs of
the current block.
Add SlotIndexes::getMBBLastIdx() method to return the last valid
SlotIndex within a basic block, enabling correct live-out calculations.
Restructure the C++ Lifetime Safety Analysis into modular components
with clear separation of concerns.
This PR reorganizes the C++ Lifetime Safety Analysis code by:
1. Breaking up the monolithic `LifetimeSafety.cpp` (1500+ lines) into
multiple smaller, focused files
2. Creating a dedicated `LifetimeSafety` directory with a clean
component structure
3. Introducing header files for each component with proper documentation
4. Moving existing code into the appropriate component files:
- `Checker.h/cpp`: Core lifetime checking logic
- `Dataflow.h`: Generic dataflow analysis framework
- `Facts.h`: Lifetime-relevant events and fact management
- `FactsGenerator.h/cpp`: AST traversal for fact generation
- `LiveOrigins.h/cpp`: Backward dataflow analysis for origin liveness
- `LoanPropagation.h/cpp`: Forward dataflow analysis for loan tracking
- `Loans.h`: Loan and access path definitions
- `Origins.h`: Origin management
- `Reporter.h`: Interface for reporting lifetime violations
- `Utils.h`: Common utilities for the analysis
The code functionality remains the same, but is now better organized
with clearer interfaces between components.
We lower signed divides by a power-of-two to ASRD. However, ASRD's
immediate is log2(shift_amount) in the range 1 to elt-bitwidth, which
means it cannot represent sdiv-by-one.
Fixes https://github.com/llvm/llvm-project/issues/162616
In order to make this easier, I also removed all "removeFromParent"
calls from the visitors, instead adding instructions
to a set of instructions to delete once the function has been visited.
This avoids crashes due to functions deleting their operands. In theory
we could allow functions to delete the
instruction they visited (and only that one) but I think having one
idiom for everything is less error-prone.
Fixes#140219
Having both SVE and SME environments essentially means the majority of
SVE2 instructions are always available. This PR reflects this at the
builtins level whereby +sve+sme is enough to enable this subset.
It's a similar story for +sve2p1 whereby the feature means a subset of
SME2 instructions are always available.
- Moved existing testcases from
```llvm/test/CodeGen/X86/fast-isel-fneg.ll``` to
```llvm/test/CodeGen/X86/isel-fneg.ll```.
- Added **x86_fp80** testcase and **GISEL** RUN lines as precommit
testcases for GISEL.
- Two i686 testcases are disabled because it is crashing in later passes
only for GISEL. It will resolve after adding **FNEG GISEL
implementation**, I will add that in next PR.
When the underlying storage element is 32-bit, we may only need half of
the last value in the uint64_t array. I've adjusted the constructor to
account for that.
For example, if you construct a 65 bit bitset you will need both 32-bit
halves of the first array value but only the bottom half of the second
value. The storage will only have 3 elements, so attempting to assign
the top 32-bits into the storage will fail.
This happened on our buildbot:
https://lab.llvm.org/buildbot/#/builders/154/builds/22555
(though the traceback is not useful)
Then added tests for < 32 bit sizes, and assertions for the number of
elements we decide to use. Given that the only member of BitSet is a
std::array, I think the size will be consistent across systems.
Tested on 32 and 64-bit Arm machines.
Follow up to #162703.
