RuntimeLibcalls: Add generic FCMP3_F* three-way compare for single-symbol ABIs
MSP430's __mspabi_cmpd/__mspabi_cmpf are one three-way compare symbol serving
every predicate, previously modeled as six suffixed impls each. Replace them
with a single generic operator FCMP3_*, and give softenSetCCOperands a 3rd
lowering option. After the boolean O*_F* and the per-predicate FCMP3_<pred>_F*
helpers, use the generic FCMP3_F* helper tested with the predicate's condition
code.
Also opt __nedf2 out of the MSP430 default set: it was the only libgcc F64
compare not already opted out, so it would otherwise provide FCMP3_UNE_F64 and
win over __mspabi_cmpd for not-equal.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
RuntimeLibcalls: Split soft-float three-way compares into distinct libcall kinds
Soft-float compares come in two flavors. ARM AEABI (__aeabi_dcmpeq) and VFP
(__eqdf2vfp) return a simple 0/1 boolean and use the existing O*_F* / UO_F*
libcalls. The libgcc/compiler-rt helpers (__eqdf2, __ltdf2, ...) return a
three-way -1/0/1, which the legalizer needs to insert the appropriate compare
against.
The three-way helpers previously masqueraded as O*_F* implementations, with the
condition code recovered from a hardcoded switch. Model them instead as distinct
operations. The legalizer then reasons about how to make use of the call result
based on which flavor of operation is available, rather than special casing what
the specific implementation is.
This leaves the mspabi cases for a later cleanup, because it's 3-way usage is
slightly different from the ARM case.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
Add some bazel libc review coverage (#209789)
This should improve timezone coverage for keeping the bazel build
working due to libc breakages, e.g. #209433 broke things and the bazel
fixer bot sent out #209689. But since it wasn't landed until just
recently, manual fixes were needed for other changes like #209449. This
wouldn't be as bad if the bazel fixer bot could handle layered
breakages.
18249 move netinet/vrrp.h to uts/common
Reviewed by: Bill Sommerfeld <sommerfeld at hamachi.org>
Reviewed by: Dan McDonald <danmcd at edgecast.io>
Approved by: Robert Mustacchi <rm+illumos at fingolfin.org>
AMDGPU: Eliminate old macro driven processor name parsing
Previously the generated inc file had a series of macros for use
with StringSwitch; now just directly scan the generated name table.
Co-authored-by: Claude (Claude-Opus-4.8)
AMDGPU: TableGen the subarch to processor name mapping table
Replace the hand-written AMDGPUSubArchNames array (SubArch -> canonical GPU
name) with a generated table.
Co-authored-by: Claude (Claude-Opus-4.8)
AMDGPU: TableGen subarch to major subarch table
Replace the hand-written AMDGPUMajorFamilies array with a
generated lookup table. Adds a special case for the major
arches missing a concrete generic target definition (we probably
should just define those to avoid this).
Co-authored-by: Claude (Claude-Opus-4.8)
[BOLT] Stop materializing .dwo DIE vectors early in the pipeline (#207292)
Summary: preprocessDWODebugInfo() eagerly force-extracted every .dwo
compile unit's DIE tree (getNonSkeletonUnitDIE(false)) very early in
BOLT pipeline, way before DWARFRewriter kicked in. Those vectors then
sit in memory throughout the entire rewrite pipeline, directly
contributing to BOLT's RSS peak. I did a fair amount of digging and
didn't find any reason as to why we need to keep all DIEs of DWO CU
materialized at all, since DWARFRewriter won't even read this vector
(the #197359 concurrency fix did use that, but that is unnecessary). The
problem is that these DIE trees are a massive contribution to RSS when
processing large binaries where we have 10s of K of dwos, storing
complete trees for each processed dwo.
This diff changes the #197359 concurrency fix to not rely on the DIE
sibling/children structure. It parses DWP type units selectively per
compile unit (DIEBuilder::buildDWPTypeUnitsForUnit ->
collectReferencedTypeSignatures) by finding the DW_FORM_ref_sig8
references in a unit's DIEs to decide which type units belong in that
[24 lines not shown]
Hexagon: Stop excluding some generic compiler-rt functions from libcalls
RuntimeLibcalls should indicate any function that exists and is callable.
Historically the list of library functions was conflated with the library
functions which should be used, so the library definition was complicated
by excluding the overridden cases. My reading of the compiler-rt sources is
that the generically named functions are built alongside the __hexagon
prefixed variants. e.g., __divsi3 and __hexagon_divsi3 both exist.
It will simplify future libcall work the fewer special case target exclusions
there are, so allow the functions to be defined and apply the selection
preference for the __hexagon prefixed versions in LibcallLoweringInfo.
I do question why compiler-rt is built this way; why doesn't the hexagon
just replace the standard entrypoint names with the target implementations?
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
