[flang] Use the ultimate symbol location for semantics-created callee names (#235808)
When a module procedure is only reachable through a use-associated
generic, semantics (`ExpressionAnalyzer::AccessSpecific`) adds a
renaming USE symbol (e.g. `m$m$nxt`) to the calling scope. This happens
both for a USE with an ONLY list that names the generic but not the
specific (e.g. `use m, only: get` where `get` resolves to the specific
`nxt`), and for a PRIVATE specific behind a PUBLIC generic accessed with
a plain `use`. The symbol's name is a saved temporary string with no
source provenance, so `getProcedureDesignatorLoc` produced an unknown
location for the callee's `func.func` declaration. Any OpenACC
`acc.routine` op attached to that function inherits the same unknown
location, which breaks consumers that expect a valid location (e.g.
optimization remarks).
When the designator symbol's name does not map to a source location,
fall back to the location of the ultimate symbol, which points into the
module file. With the module in a separate file, the declaration now
gets e.g. `loc("m.mod":10:10)`, matching what a plain `use m` of a
[9 lines not shown]
[mlir][tensor] Fix crash in ConvertToStaticExpandShape with negative constant output dims (#233804)
`ConvertToStaticExpandShape` trusts any constant `output_shape` entry to
be a valid dimension. The constant is produced by canonicalization
itself
(an `arith` chain folds to `-5`), the verifier never sees it, and the
negative value reaches `RankedTensorType::get`, aborting with "invalid
tensor dimension size".
Decline the rewrite before any mutation (`if (dim < 0) return
failure();`).
`dim < 0` rather than `!= kDynamic`, since `kDynamic` is `INT64_MIN` and
`-1` is invalid too. A negative dimension means the op has no valid
execution, so declining preserves all valid programs.
Fixed #233053.
Assisted-by: AI.
[scudo] Remove redundant getHeaderTaggedPointer() call. (#235136)
Pass in the already computed value of getHeaderTaggedPointer() to
quarantineOrDeallocateChunk().
[libc][regex] Add POSIX character classes and shorthands (#234991)
POSIX ERE character class expressions like [:alpha:] and [:digit:] allow
portable character classifications inside bracket expressions, while
common escape shorthands (\d, \D, \s, \S, \w, \W) provide concise
alternatives for character classes. In POSIX regular expressions,
character classes inside brackets must correctly reject unknown class
names with REG_ECTYPE, reject range endpoints involving classes with
REG_ERANGE, and integrate with negated bracket sets and REG_NEWLINE.
Add regex_charclass.h containing lookup_posix_class to map all 12 POSIX
classes (alnum, alpha, blank, cntrl, digit, graph, lower, print, punct,
space, upper, xdigit) to constexpr 256-bit bitsets in the POSIX/C
locale. Support operator|= in bitset.h for bitset composition. In
parse_bracket_expr, recognize [:name:] sequences, enforce REG_ECTYPE on
invalid names, reject class endpoints with REG_ERANGE, and reserve word
boundary anchors [[:<:]] and [[:>:]] with REG_BADPAT until word anchor
support lands. Support shorthands \d, \D, \s, \S, \w, and \W in
parse_quantified_atom, clearing newlines on negated shorthands when
[7 lines not shown]
[bazel] Port f85dfbe93cfb (#235890)
Add the new internal header
lib/DebugInfo/DWARF/DWARFExpressionPrinterImpl.h to the srcs of
DebugInfoDWARF.
Assisted-by: Gemini
[AMDGPU] Fix sc1 encoding of gfx940 fp atomics with AGPR results
The *_F64 FLAT and GLOBAL atomics have separate VI and GFX940 reals,
because the VI reals are defined with has_sccb=0 and so do not encode
bit 25, which is SC1 on GFX940. However:
- #129668 removed the isGFX90AOnly predicate from the VI reals, so on
GFX940+ both the VI and GFX940 reals matched in the assembler. The
GFX940 ones happened to win because they were defined later.
- The GFX940 multiclasses did not define *_RTN_agpr reals, so the AGPR
forms of the returning atomics always used the VI reals on GFX940+.
The assembler silently dropped sc1 for these, the disassembler could
not decode them with sc1 set, and codegen dropped sc1 from the
*_RTN_agpr pseudos.
Fix this by adding *_RTN_agpr (and *_SADDR_RTN_agpr) reals to the GFX940
atomic multiclasses, and restricting the VI f64 reals to
isGFX8GFX9NotGFX940, like the neighbouring f32 and pk_f16 ones.
[6 lines not shown]
[LoopInterchange] Interchange loops by remapping induction variables
This is the main part of #235496. Before this patch, interchanging the
loops was achieved by splitting BBs and rewiring PHIs and branches.
This method is complicated and has caused several bugs. This patch
changes the way to achieve interchange so that the original CFG is kept
as it is. Instead of changing the control flow, this patch interchanges
the loops by using the counter of each loop to make it run as many
iterations as the other loop did, and by swapping IV-related variables
between the outer and inner loops. Also, in addition to simplifying the
logic, this approach doesn't create new BBs unlike the previous method,
so the generated IR is relatively clean.
The existing legality checks already rule out most of the loops to
which this transformation cannot be applied, so most of the changes are
confined to the transformation phase. The legality checks are changed
as follows:
- Loops where a branch before the inner loop depends on the outer IVs
[11 lines not shown]
[mlir][vector-to-gpu] Do not prepare masked contractions for MMA (#226732)
GPU MMA operations do not support masking, so a `vector.contract` nested
in `vector.mask` cannot be converted to them.
`PrepareContractToGPUMMA` and `CanonicalizeContractMatmulToMMT` still
rewrite such contractions without correctly preserving the enclosing
`vector.mask`.
Bail out on masked contractions in both patterns. They stay in Vector
form, while eligible unmasked contractions are still converted.
This form can arise on partial remainder tiles of a peeled and
vectorized matmul.
Part of #227821.
Assisted-by: Claude (Anthropic)
[mlir][SPIRVToLLVM] Emit client API warning without attaching the module (#235750)
Attaching the op printed and verified the whole module on every
non-OpenCL input
[CodeGen] Fix TBAA verification failure when copying volatile C structs (#226615)
This fixes two bugs in GenBinaryFunc::visitVolatileTrivial
(CGNonTrivialStruct.cpp):
- It was passing the field's type instead of the containing struct's
type to MakeAddrLValue.
- It was calling EmitLoadOfLValue and EmitStoreThroughLValue even when
the lvalue was an aggregate or a _Complex type. The functions end up
calling EmitLoadOfScalar/EmitStoreOfScalar, which are meant to be used
only for scalar values.
Both caused CodeGen to emit incorrect TBAA metadata, which made the IR
verifier fail.
rdar://187077389
[mlir][LLVM] Fix crash combining nested pointer data layouts (#222855)
While investigating #222356, an LLVM pointer data layout compatibility
crash was found when combining nested layouts.
`LLVMPointerType::areCompatible()` passed the `DataLayoutEntryInterface`
itself to `extractPointerSpecValue()`, even though that helper expects
the entry value as a `DenseIntElementsAttr`.
Use `getValue()` for the enclosing pointer entry, matching the handling
of the nested entry and allowing compatible pointer layouts to be
combined without asserting.
The separate builtin data layout combination issue found during the same
investigation is handled independently.
Related to #222356.
AI-assisted tooling was used during development and validation.
[LoopInterchange] Replace exit conditions of interchanged loops with counters
In the transformation phase of LoopInterchange, the exit condition of
the inner loop is reused by cloning the instructions involved in it and
moving them into a new BB. Handling all PHI nodes correctly in this way
is difficult, and it has caused several bugs.
Instead, this patch introduces a new way to control the interchanged
loops: add a new variable that works just as a loop counter, and compute
the exit condition from it and the original BTC. The induction variables
that were used only to compute the original exit conditions are deleted.
This makes the logic simpler, since the computation of the original exit
condition no longer needs to be moved.
Part of #235496
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[LoopInterchange] Drop loop metadata and branch weights of interchanged loops
This patch drops the loop metadata and the branch weights of the latches
when interchanging loops. As for the loop metadata, some attributes may
no longer hold after interchange (e.g., parallel_accesses of the inner
loop), and its semantics are partially ambiguous (e.g., what should we
do with unroll_and_jam?), so it is conservatively removed for now. As
for the branch weights, I believe we don't need to drop them
unconditionally, but they are also conservatively removed (or marked as
unknown if the function has profile data) for now. Moving them to the
appropriate place is left as future work.
Note: I'm not entirely sure that dropping these is sufficient. Please
let me know if there are other kinds of data that should be dropped when
interchanging loops.
Part of #235496
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[LoopInterchange] Require loop control values to be expandable in the outer preheader
This patch slightly changes the legality check in preparation for later
patches. Specifically:
- Loops whose inner IVs have initial values that are outer loop
invariant but neither constants nor instructions (e.g., function
arguments) become interchange candidates.
- Loops where the BTC of the inner loop is computed inside the outer
loop (more precisely, cannot be expanded in the outer loop preheader)
are no longer candidates.
As far as I tried, this change doesn't affect most cases.
Part of #235496
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
Reapply "[LoopInterchange] Add tests for loop control values in the outer preheader (NFC)" (#235520)
This reverts commit 063d4816ce9051924a61f5d1e31a05992ca221b8.
Add test cases where it matters whether the loop control values (the
initial and final values of the IVs) are available in the outer loop
preheader. These are corner cases where the work in #235496 changes
what loop-interchange can handle.
The original commit was reverted because one of the tests failed with
EXPENSIVE_CHECKS due to stale SCEV dispositions (#221571). This has
been fixed by #222175 (not yet, but it will be). This reapply also adds
-verify-scev to the RUN line so that the issue is caught without
EXPENSIVE_CHECKS.
Part of #235496
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[LoopInterchange] Add tests for loop metadata, debug info, and IV updates (NFC)
Add test cases to ensure that later patches correctly handle the
following:
- Loop metadata and branch weights on the latches.
- Debug records that refer to the outer IVs.
- Various forms of IVs, e.g., pointer IVs, non-constant steps, and start
values computed in the outer loop.
- Code in the outer loop but outside the inner loop that uses the outer
IVs.
- Interchanging the same pair of loops twice.
Part of #235496
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[SelectionDAG] Improve operand promotion for concat vectors. (#234070)
Create a new concat of legal type and then truncate it to the correct
size instead of creating a build vector.
[lldb] Create COFFObjectFile directly in ObjectFilePECOFF (#229797)
`ObjectFilePECOFF` calls `llvm::object::createBinary` and then requires
the result to be a `COFFObjectFile`. `createBinary` dispatches to every
object file format, so it links all of them into lldb-server.
`MagicBytesMatch` has already established that the file is PE/COFF, so
call `COFFObjectFile::create`.
[C++20][Modules] Omit imported PCM file info for explicitly mapped header units (#235597)
C++20 named module dependencies are already serialized without PCM file
information. This PR applies the same behavior to header units loaded through
a named mapping (`-fmodule-file=<name>=<pcm>`). Header units loaded
through `-fmodule-file=<file>` retain their file information.
An explicit `IsCXX20ModuleOrPrebuiltHeaderUnit` field is added to
the `IMPORT` record rather than reusing `StandardCXXModule`, which
also controls imported-module lookup.
This also adds a missing test for the existing named-module behavior and
tests the corresponding header-unit behavior introduced by this change.
[TableGen] Use "parent class" terminology in TGParser. NFC. (#235106)
TGParser called the classes and multiclasses that a record or multiclass
inherits from "subclasses", for example in AddSubClass and
SubClassReference, although they are its parent classes. Rename them to
match the terminology of the TableGen grammar in ProgRef, e.g.
AddParentClass and ClassReference, and update the comments
accordingly, including the grammar comments.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply at anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply at anthropic.com>
[AMDGPU] Fold high-half extracts into op_sel for i16 mad (#231410)
Use the VOP3OpSel complex pattern for the sources of the i16 mul+add
patterns that select the op_sel-capable v_mad_u16 on GFX10+, so that a
source taken from the high half of a packed register is read with op_sel
instead of being extracted with a shift first.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply at anthropic.com>
[DebugInfo] Salvage replaced sdiv instructions (#234602)
When `correlated-propagation` removed SDiv instructions, it doesn't
correctly salvage the debug information. This leads to variables in the
debugger having incorrect values. This patch makes sure we salvage the
debug information correctly.
(See https://github.com/llvm/llvm-project/issues/218630, which this
fixes)
[AMDGPU] Fix sc1 encoding of gfx940 fp atomics with AGPR results
The *_F64 FLAT and GLOBAL atomics have separate VI and GFX940 reals,
because the VI reals are defined with has_sccb=0 and so do not encode
bit 25, which is SC1 on GFX940. However:
- #129668 removed the isGFX90AOnly predicate from the VI reals, so on
GFX940+ both the VI and GFX940 reals matched in the assembler. The
GFX940 ones happened to win because they were defined later.
- The GFX940 multiclasses did not define *_RTN_agpr reals, so the AGPR
forms of the returning atomics always used the VI reals on GFX940+.
The assembler silently dropped sc1 for these, the disassembler could
not decode them with sc1 set, and codegen dropped sc1 from the
*_RTN_agpr pseudos.
Fix this by adding *_RTN_agpr (and *_SADDR_RTN_agpr) reals to the GFX940
atomic multiclasses, and restricting the VI f64 reals to
isGFX8GFX9NotGFX940, like the neighbouring f32 and pk_f16 ones.
[6 lines not shown]
[AMDGPU] Precommit tests for gfx942 fp atomics with AGPR results (#232059)
Add MC, disassembler and codegen tests for FLAT and GLOBAL fp atomics on
gfx942 and gfx950, with more complete coverage of the f64 atomics on
gfx90a and gfx942.
The returning forms of {flat,global}_atomic_{add,min,max}_f64 with AGPR
operands currently use the *_RTN_agpr_vi reals on gfx942, which do not
encode bit 25 (SC1), so:
- the assembler silently drops sc1
- the disassembler fails to decode them with sc1 set
- the *_RTN_agpr pseudos are lowered without sc1
Similarly for global_atomic_add_f32 and global_atomic_pk_add_f16, where
codegen drops sc1 from the *_RTN_agpr pseudos, and the assembler and
disassembler reject the AGPR returning forms altogether.
The codegen test is written in MIR because nothing currently selects the
[13 lines not shown]
[lldb-dap][docs] Note the version that introduced an extension (#235773)
Record the LLDB release each lldb-dap extension first shipped in.
To avoid user creating issue of missing fields. similar to
https://github.com/llvm/llvm-project/issues/161998
[offload][omp] Remove data_fence
All supported backends execute enqueued work on a given queue in
submission order (CUDA, AMDGPU, and Host queues are always in-order;
Level Zero's default and non-default in-order/synchronous command
modes are as well), so the explicit data-fence used to order a
pointer-attachment after prior data transfers is unnecessary. Remove
the DeviceTy/GenericDeviceTy/GenericPluginTy dataFence chain and the
now-unused olQueueBarrier liboffload API added to support it.
[LLDB] Use `-fastproxy` when building swig bridge without limited python API (#234206)
Per [swig
docs](https://www.swig.org/Doc4.4/Python.html#Python_fastproxy).
Additionally, the `-olddefs` option is included so that the doc comments
still function. The latter change makes importing the LLDB module a bit
slower, but makes every method call a good bit faster.
Co-authored-by: Jonas Devlieghere <jonas at devlieghere.com>
