[Docs] don't stylize syntax errors in code blocks (#212698)
When a code block in the documentation contains (almost) pseudocode, the
Pygments parser flags errors and renders them with red-bordered boxes.
This is unnecessarily ugly. We can see examples of this in the LangRef
with LLVM code blocks.
Instead set the style to just render them as plain text. This is still
recognizable as incorrect syntax, but does not distract the reader from
the actual example.
Assisted-by: Claude Opus 4.8
[SystemZ][z/OS] Implement emitCommonSymbol in MCGOFFStreamer (#210179)
Common globals were not emitted in GOFF object files due to a missing
emitCommonSymbol implementation. This adds the implementation to emit
the required SD/ED/PR ESD records in the GOFF object file.
[PAC][clang][test] Fix incorrect usage of `-NOT` suffix for FileCheck (#212445)
Previously, `-NOT` checks were not doing what was intended: checking
that given strings are not present within the same line where other
patterns are confirmed present by other checks. `-NOT` semantics is
checking pattern absense in between other checks, not total absense.
This patch makes use of `--implicit-check-not` instead for this purpose.
[ProfileData] Implement contains in SampleProfileNameTable (NFC) (#211995)
This patch implements contains(StringRef) and contains(uint64_t) in
SampleProfileNameTable and SampleProfileReader to serve symbol
membership queries directly from the reader -- "is this symbol in the
name table?".
Without this patch, users of the sample profile reader, namely
SampleProfileLoader::doInitialization and SampleProfileNameSet, each
construct their own StringSet<> containing all name table entries.
That is, we end up with two instances of StringSet<> with identical
contents. Since these instances hold their own copies of symbol
strings on the heap, both the constructor and destructor take up a
large portion of compilation time.
This patch teaches SampleProfileReader::contains to directly serve
symbol membership queries.
- For EytzingerSampleProfileNameTable, contains performs binary search
[11 lines not shown]
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.
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>
ARM: Mark more generic libgcc functions as available
Generic libgcc/compiler-rt functions coexist with aeabi variants
(e.g., __divsi3 and __aeabi_idiv) according to my reading of the
build. At least in compiler-rt, they are aliases (such that I'm not sure
what the point of ever emitting the __aeabi name is).
They were previously removed from the available set on AEABI+AAPCS targets
to force selection of the preferred __aeabi_* variants, back when
only one implementation per libcall could be recorded.
Now that multiple implementations can be available per libcall, stop hiding
the generics and select the __aeabi_* variant explicitly as the preferred
implemntation. This reduces the number of special cases to consider for
future libcalls info improvements.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
RuntimeLibcalls: Emit all available impls for a libcall, not just one
The intent is RuntimeLibcalls should represent all functions that are
callable from the module, which may have contextually selectable alternatives.
Previously we had this warning since there was no mechanism to select which
one you want, and as a workaround the library call sets avoided adding the
variants which should nto be selected.
Now targets can use initLibcallLoweringInfo, so remove the warning to unblock
more libcall cleanups. Eventually initLibcallLoweringInfo should also be tablegen
driven.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
MSP430: Mark more generic libgcc functions as available (#210962)
The generic soft-float, conversion, comparison and integer helper
routines (__addsf3, __divli's __divsi3, __ashlsi3, ...) exist in the MSP430
libgcc port alongside the preferred __mspabi_* variants. They were previously
removed to force selection of the __mspabi_* names, back when only one
implementation per libcall could be recorded.
Stop hiding them: only __lshrsi3 stays excluded, since the MSP430 libgcc
port provides the 32-bit logical right shift solely under __mspabi_srll and
never defines a generic __lshrsi3.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[flang][semantics] Accept BOZ initializers for C enum values (#211904)
Fortran 2023 7.6.1 errata f23/013 changes R762 so an interoperable
enumerator may be a named-constant initialized by a
boz-literal-constant, and specifies the value as
INT(boz-literal-constant, C_INT).
Handle that named-constant restriction directly in enum resolution while
preserving the usual scalar integer expression checks for non-enumerator
contexts. This mirrors the general named-constant initializer path,
which already converts BOZ values through the declared type before
folding.
AMDGPU: Handle more TargetParser queries in tablegen
Previously we had various enum switches. Start generated tables
indexed by enums. Avoid some special cases by defining the dummy
"generic" and "generic-hsa" targets as real processors.
Co-authored-by: Claude (Claude-Opus-4.8)
[MLIR] Fix transform.apply_patterns with apply_cse option (#212818)
This patch fixes a crash in `transform.apply_patterns` when `apply_cse`
is enabled and the target operation does not have the
`IsolatedFromAbove` trait.
For non-`IsolatedFromAbove` targets, `transform.apply_patterns` cannot
apply patterns directly to the target operation. Instead, it collects
the operations within the target into a worklist and passes that
worklist to `applyOpPatternsGreedily`. When `apply_cse` is enabled,
pattern application and CSE are performed repeatedly until a fixpoint is
reached.
Previously, the worklist was collected only once before entering the
fixpoint loop. However, pattern application may erase operations from
the IR, leaving stale pointers in the cached worklist. Reusing this
worklist in subsequent iterations may therefore result in a crash.
This patch rebuilds the worklist at the beginning of each iteration,
[45 lines not shown]
