[AMDGPU] Price scalar integer to fp casts by source width and sign
Scalar sources between a byte and 31 bits fell to the default cost of one
while the matching vector lanes were already priced, which skewed the
difference SLP weighs a bundle against. Such a source is extended before
the conversion, and what the extension takes depends on the width, on the
sign and on whether the subtarget has SDWA and 16 bit instructions.
Sources narrower than a byte are left alone, because their vector form is
not priced either.
[AMDGPU] Price narrow integer to bfloat vector casts
A vector lane of 9 to 15 or 17 to 31 bits converted to bfloat got the
generic cost, which leaves out the rounding. Such a lane is converted to
f32 first like any other narrow lane, so price it as the f32 conversion of
the same source plus the rounding. Lanes of 8 and 16 bits keep their cost.
[AMDGPU] Model the cost of the expanded integer to/from floating point casts
No instruction converts to or from a 64 bit integer, and narrow vector
lanes are converted one at a time. Price these expansions by the FP64
rate, sdwa and 16 bit instruction support, and price i33 to i63 like
i64 and bf16 like f32 plus rounding.
Assisted-by: Claude Code Opus 5
[NFC][AMDGPU] Add cost tests for narrow integer to fp casts
Covers integer sources from a byte to 31 bits converted to half, float,
bfloat and double, as vector lanes and as scalars, over the subtarget
combinations that change the expansion. The existing cast tests get the
same subtarget coverage and the cases they were missing. The costs
recorded here are the ones the model reports today.
[LV] Remove EpilogueLoopVectorizationInfo::EpilogueUF (NFC). (#226792)
The epilogue vector loop is always unrolled by 1: the only construction
site passes 1 and the constructor asserted it. Drop the field and use 1
directly at its users, and drop the now always 1 EpilogueUF parameter of
addMinimumVectorEpilogueIterationCheck.
Clean-up in preparation for removing/simplifying
EpilogueLoopVectorizationInfo.
CodeGen: Merge TargetLoweringObjectFile::getModuleMetadata into Initialize
getModuleMetadata had a single caller, which invoked it immediately after
Initialize. Pass the module to Initialize and fold it in.
Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>
CodeGen: Initialize TargetLoweringObjectFile from MachineModuleInfo
MachineModuleInfo passes TLOF to the MCContext the TargetLoweringObjectFile
but nothing initialized it until the AsmPrinter pass ran, so every codegen pass
in between saw it uninitialized. Initialize it from MachineModuleInfo, and drop
the calls llc and SPIRVTranslate used to work around this.
SPIRVTranslate's MachineModuleInfoWrapperPass was never passed on to
addPassesToEmitFile, so it was initializing a throwaway context.
Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>
lft: update to 4.03.
lft 4.03 / WhoB 4.03
----------------------
- NetBSD: interface lookup by address found nothing (SIOCGIFCONF entries are
fixed-size there, unlike FreeBSD/macOS), so LFT could not pick its capture
interface. lft_getifname now uses getifaddrs() where available and strides
the ioctl list correctly everywhere else.
- NetBSD: lft aborted at startup ("_res is not supported for multi-threaded
programs") because c-ares links libpthread and NetBSD's libc forbids _res
there; the glibc-only resolver timeout tweak is now skipped on NetBSD.
- Build: objects depend on the generated config header, so a re-configure
rebuilds them.
[unittests] Fix a recent test on Windows with LLVM_WINDOWS_PREFER_FORWARD_SLASH (#224963)
This fixes errors like these:
```
Expected equality of these values:
Context.Path
Which is: "D:/a/llvm-mingw/llvm-mingw/llvm-project/build/unittests/Support/LLVMToolSession/./LLVMToolSessionTests.exe"
ExecutablePath.c_str()
Which is: "D:\\a\\llvm-mingw\\llvm-mingw\\llvm-project\\build\\unittests\\Support\\LLVMToolSession\\.\\LLVMToolSessionTests.exe"
```
