[AArch64] Tighten conditions for expanding GET_ACTIVE_LANE_MASK (#208962)
Lower to whilelo in more cases.
For fixed-width even if the operands are <32 bits, expanding is going to
be more expensive compared to promoting the operands from a smaller
type.
For SVE I also added lowering for nxv1i1 type as: `nxv2i1 -> extract
nxv1i1.`
Revert "[libc++][NFC] Inline std::function members into the class body" (#209555)
Reverts llvm/llvm-project#209461
This is breaking LLDB testing bots and it also failed pre-merge CI.
[NFC] Rename misleading `msvcrt` comment in `Windows/DynamicLibrary.inc` (#208884)
The comment in function `DynamicLibrary::HandleSet::DLSym` referred to
the mysterious `msvc.dll` windows standard dynamic library which simply
doesn't exist and `msvcrt.dll` was likely meant, so fix the comments.
[flang][OpenMP] Resolve private array source from block-arg owner in alias analysis (#208227)
Part of #208086. `fir::AliasAnalysis::getSource` fails to recognize an
OpenMP private array as an `Allocate` source when its `hlfir.declare` is
nested inside an omp.loop_nest, and conservatively returns `MayAlias`.
This changes `getSource` to resolve the clause-carrying OpenMP op from
the private block argument's owner region, so the private is correctly
classified and does not spuriously alias other objects. Assisted-by: Copilot
AMDGPU: Migrate CodeGen tests to amdgpu subarch triple (26) (#209487)
Mechanically migrate the command-line target spelling on llc/opt RUN
lines in llvm/test/CodeGen/AMDGPU from -mtriple=amdgcn ... -mcpu=<gfx> to the
folded subarch triple form (e.g. -mtriple=amdgpu9.00-amd-amdhsa), dropping the
redundant -mcpu.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
[VPlan] Expand SCEV ptrtoint/ptrtoaddr casts in VPSCEVExpander. (#209172)
Extend the cast handling in VPSCEVExpander::tryToExpand to also expand
scPtrToInt and scPtrToAddr SCEV expressions to PtrToInt/PtrToAddr
VPInstructions.
This allows pointer-distance expressions (e.g. the runtime-check
difference between two pointers, which contains ptrtoint of each
pointer) to be expanded directly to VPInstructions instead of falling
back to a VPExpandSCEVRecipe.
PR: https://github.com/llvm/llvm-project/pull/209172
AMDGPU: Migrate CodeGen tests to amdgpu subarch triple (25) (#209486)
Mechanically migrate the command-line target spelling on llc/opt RUN
lines in llvm/test/CodeGen/AMDGPU from -mtriple=amdgcn ... -mcpu=<gfx> to the
folded subarch triple form (e.g. -mtriple=amdgpu9.00-amd-amdhsa), dropping the
redundant -mcpu.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
AMDGPU: Migrate CodeGen tests to amdgpu subarch triple (24) (#209485)
Mechanically migrate the command-line target spelling on llc/opt RUN
lines in llvm/test/CodeGen/AMDGPU from -mtriple=amdgcn ... -mcpu=<gfx> to the
folded subarch triple form (e.g. -mtriple=amdgpu9.00-amd-amdhsa), dropping the
redundant -mcpu.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
[mlir][openacc] Remove OpenACCToLLVMIRTranslation (#209295)
OpenACCToLLVMIRTranslation was designed more than 5 years ago and does
not align with the current upstreaming effort. OpenACC will be converted
to LLVM IR dialect before the translation to LLVM IR so this translation
is obsolete. Remove it to avoid confusion.
Fix test that had a check embedded which depended on the current LLVM version number. (#209530)
When the test was refactored, it embedded the current LLVM version
number in one of the check strings so that when I bumped the LLVM
version to 24, the test failed since it was expecting 23 but the
compiler was now generating 23.
Fix this issue by changing the check to a regex so it doesn't need
updating after every LLVM version change.
AMDGPU: Migrate CodeGen tests to amdgpu subarch triple (23) (#209214)
Mechanically migrate the command-line target spelling on llc/opt RUN
lines in llvm/test/CodeGen/AMDGPU from -mtriple=amdgcn ... -mcpu=<gfx> to the
folded subarch triple form (e.g. -mtriple=amdgpu9.00-amd-amdhsa), dropping the
redundant -mcpu.
Co-Authored-By: Claude <noreply at anthropic.com> (Claude-Opus-4.8)
[libc][cpp::string] Don't allocate a string in operator=(string_view)
This PR:
- Updates `opreator=(string_view)` to avoid allocating a temporary string: https://github.com/llvm/llvm-project/blob/67ebc4b221c3e94028b33004cd5cd08deee95048/libc/src/__support/CPP/string.h#L106-L108
- Changes `operator+=(const string&)` to accept a `string_view` so that strings may be appended without allocation.
- Adds asserts to make it clear that `cpp::string` does not support self assignment. Currently, `cpp::string s = "abc"; s = s;` will zero out the string.
[Clang] Require x86 target for some tests (#209532)
These tests assert behavior about the always-inliner which now requires
a target to be present to check function attribute compatibility for
inlining.
Fix forward for 37b8e765ce4837a7577e6f762bcdffe4b232759c.
[clang][cuda] Use the source filename for module ID (#209239)
Prior to
[#184065](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html
"https://github.com/llvm/llvm-project/issues/184065") (relanded in
[#201849](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html
"https://github.com/llvm/llvm-project/issues/201849")), the code
introduced in https://reviews.llvm.org/D42922 was using the GUID of an
internal linkage GlobalValue to create a module id, which would then be
used in a few cuda-specific places (including creating a symbol name
suffix).
[#184065](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html
"https://github.com/llvm/llvm-project/issues/184065") assumed the
linkage of that symbol is external - which it isn't - and, thus, all
module IDs computed for this would be identical.
The fix is to not rely on GlobalValue GUIDs in the first place. What is
needed here is a hash that's specific to this module. So we're creating
that and explicitly decoupling that calculation from GlobalValue's
[8 lines not shown]
[VPlan] Use VPlan::hasTailFolded in materializeConstantVectorTC. (#209502)
The current checks in materializeConstantVectorTripCount miss
tail-folded cases when vectorizing loops with fmax without fast-math
flags. Use recently added hasTailFolded helper to ensure we always bail
out on tail-folded loops.
Fixes https://github.com/llvm/llvm-project/issues/209159.
[Hexagon] Add lowering for `{max,min}num` (#202938)
Since the floating point requirements for `{max,min}num` are less strict
than the ones for `{max,min}imumnum`, it is fine to lower them to the
same instructions that already meet the requirements for the latter.
This is similar to what the RISC-V backend does for example.
This is also a lot better than generating a standard library call.
[AMDGPU] Fix CFI emission when scratch instructions are used to spill
4b1cfc5d7c606e "[NFCI][AMDGPU] Final touch before moving to
`GET_SUBTARGETINFO_MACRO` (#177401)" (or more generally the move to
hasFlatScratchEnabled over just enableFlatScratch) was missed during the
CFI upstreaming for AMDGPU, and so we currently define the CFA
incorrectly for the architected flat scratch case.
This incorrect CFI is generated for e.g. gfx942. For such architecture,
the stack pointer (s32) holds a swizzled address (per-lane offset) but
the CFA needs to be an unswizzled address (per-wave).
In the incorrect program, we have a prologue looking like:
s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
s_mov_b32 s0, s33
s_mov_b32 s33, s32
[...]
s_add_i32 s32, s32, 16
[24 lines not shown]
