ValueTracking: Generalize known frexp exponent range to any constant
Extend computeKnownExponentRangeFromContext beyond the special case of a
dominating fabs(V) compare against exactly 1.0 to any finite limit.
Generalizing below 1.0 exposes a soundness issue: frexp(0) has exponent
0, so a bound derived assuming a nonzero value could wrongly exclude it
when the limit implies a negative maximum exponent. Query fcZero and clamp
the maximum exponent to at least 0 when the source may be zero.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[lldb-mcp] Replace byte forwarding with a protocol-aware multiplexer (#208506)
To serve several LLDB instances behind one endpoint it has to act as a
multiplexer. This PR adds a Multiplexer that presents a unified MCP
server to the client. It answers initialize and tools/list locally, and
forwards tools/call and the resource requests to the different instances
through an mcp::Client (added in #208371), relaying the answer back.
For now, this still drives a single backend. Discovering and routing
across several instances is coming next.
Assisted-by: Claude
Reapply "[PGO][ICP] Prevent indirect call promotion to functions with incompatible target features" (#208774)
Reverts llvm/llvm-project#208079
We're still seeing build failures without this, so reapply for now.
[mlir][xegpu] Add support for 1D SLM case in vector-to-xepgu (#208276)
Currently vector-to-xegpu only support 2D SLM buffers. However
load/store_matrix op definition allows 1D access.
Assisted by: Claude
clang/AMDGPU: Forward host system includes in offload compiles
Commit 640079288c5e merged the AMDGPU toolchain subclasses but dropped the
HIPAMDToolChain::AddClangSystemIncludeArgs override, which forwarded to the
host toolchain.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[Hexagon] Fix wrong operand in XQFloat qf32 multiply normalization (#208489)
In convertNormalizeMultOp32, when only the second operand of a
V6_vmpy_qf32 comes from an add/sub/mul unit (secondconvert), the
generated multiply incorrectly used the raw second operand (Reg2)
instead of the first operand (Reg1). This dropped the first operand and
multiplied the normalized second operand by the un-normalized second
operand.
This patch fixed the multiply to use Reg1 and the normalized input_mpy2,
matching the correct arrangement used elsewhere. The bug was not
observed on v81 (which takes the V81normalizeMultF32 path); it only
affected the v79 fallback.
Co-authored-by: Santanu Das <quic_santdas at qti.qualcomm.com>
[clang] Fix constexpr placement new of arrays. (#196669)
The existing code tried to implement a overly generous rule, and it
didn't really work. Restrict the accepted constructs to what we can
easily support. Adjust the representation of the destination pointer to
match the array which will be constructed.
Fixes #117294
ValueTracking: Fix off by one in known frexp exponent range (#208295)
Also restrict the optimization to the exactly 1 case for now.
There was an additional bug for values less than 1 to be fixed
separately.
Fixes #208192
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[alpha.webkit.UncountedCallArgsChecker] Improve the warning text (#202724)
This PR improves UncountedCallArgsChecker and its variant's warning
message to explicitly state the argument expression, the qualified
callee type as well as the type which needs to be kept alive.
[Github] Add ids container (#208498)
This will be used for the ids check workflow. This will enable us to use
a PGO optimized compiler that we also use elsewhere, which should help
speed up the builds on top of reducing redundant work like needing to
configure/build ids for every job. This also makes things a bit more
hermetic.
This is a bit of a hack with how the ids build is setup now (e.g.,
copying over libLLVM.so), but that's something that can be rectified
pretty easily later.
cmake: Derive CMake system name from a triple via new mechanism
This is a reimplementation of the cmake functionality first implemented in
6e4e181c83, which has now been reverted twice. Implement the raw cmake functionality
without introducing the uses yet.
The runtimes build needs to translate the build target (configured with a target
triple) to cmake's naming scheme, to use for CMAKE_SYSTEM_NAME. Use the OS/environment
list from TargetParser as the source of truth; add an additional entry for the
cmake name to ensure the build system and compiler always recognize the same set
of names.
Upgrade the previous cmake regexes to a new python script which parses the
authoritative def file. The new script logic should match Triple::normalize's
permissiveness for various legacy and malformed triple shapes. This should be
more maintainable than the previous cmake regexes, since there's now a unit test
mirroring the triple unit test.
Co-Authored-By: Claude (Opus 4.8) <noreply at anthropic.com>
cmake: Derive CMake system name from a triple via new mechanism
This is a reimplementation of the cmake functionality first implemented in
6e4e181c83, which has now been reverted twice. Implement the raw cmake functionality
without introducing the uses yet.
The runtimes build needs to translate the build target (configured with a target
triple) to cmake's naming scheme, to use for CMAKE_SYSTEM_NAME. Use the OS/environment
list from TargetParser as the source of truth; add an additional entry for the
cmake name to ensure the build system and compiler always recognize the same set
of names.
Upgrade the previous cmake regexes to a new python script which parses the
authoritative def file. The new script logic should match Triple::normalize's
permissiveness for various legacy and malformed triple shapes. This should be
more maintainable than the previous cmake regexes, since there's now a unit test
mirroring the triple unit test.
Co-Authored-By: Claude (Opus 4.8) <noreply at anthropic.com>
