LLVM/project cae36e3clang-tools-extra/clang-doc BitcodeWriter.cpp BitcodeWriter.h

[clang-doc] Clean up inconsistent namespace usage in BitcodeWriter (#198067)

Typically we forgo prefixing things with clang::doc or llvm:: unless
they overlap with something in std::, like `to_underlying()`. We also
group things to avoid non-internal symbols by placing types in the
anonymous namespace, and more logically grouping things that don't need
to be in the clang::doc namespace.
DeltaFile
+56-61clang-tools-extra/clang-doc/BitcodeWriter.cpp
+2-3clang-tools-extra/clang-doc/BitcodeWriter.h
+58-642 files

LLVM/project 135ec89clang-tools-extra/clang-doc YAMLGenerator.cpp

[clang-doc][nfc] Use static declarations to enforce internal linkage
DeltaFile
+4-4clang-tools-extra/clang-doc/YAMLGenerator.cpp
+4-41 files

LLVM/project 8479c32clang-tools-extra/clang-doc Serialize.cpp

[clang-doc][nfc] Declare pointer with auto explicitly

This silences some errors from clang-tidy.
DeltaFile
+1-1clang-tools-extra/clang-doc/Serialize.cpp
+1-11 files

LLVM/project 6ba1937clang-tools-extra/clang-doc Serialize.cpp

[clang-doc][nfc] Silence tidy warning about anonymous namespace

clang-tidy complains that we should prefer static over the anonymous
namespace, despite the API being static in addition to being in the
anonymous namespace. We can silence the diagnostic by simply removing
the namespace declaration.
DeltaFile
+0-2clang-tools-extra/clang-doc/Serialize.cpp
+0-21 files

LLVM/project 265c199clang-tools-extra/clang-doc Representation.cpp YAMLGenerator.cpp

[clang-doc][nfc] Prefer range based APIs
DeltaFile
+2-2clang-tools-extra/clang-doc/Representation.cpp
+2-1clang-tools-extra/clang-doc/YAMLGenerator.cpp
+4-32 files

LLVM/project 44f6ed1clang-tools-extra/clang-doc ClangDoc.cpp YAMLGenerator.cpp

[clang-doc] Use explicit for single param constructors

This trips up some clang-tidy checks, so add the explicit keyword as
needed to satisfy the lints.
DeltaFile
+2-2clang-tools-extra/clang-doc/ClangDoc.cpp
+2-2clang-tools-extra/clang-doc/YAMLGenerator.cpp
+1-1clang-tools-extra/clang-doc/Serialize.cpp
+1-1clang-tools-extra/clang-doc/BitcodeWriter.cpp
+6-64 files

LLVM/project e39e466clang-tools-extra/clang-doc BitcodeWriter.cpp BitcodeWriter.h

[clang-doc] Clean up inconsistent namespace usage in BitcodeWriter

Typically we forgo prefixing things with clang::doc or llvm:: unless
they overlap with something in std::, like `to_underlying()`. We also
group things to avoid non-internal symbols by placing types in the
anonymous namespace, and more logically grouping things that don't need
to be in the clang::doc namespace.
DeltaFile
+56-61clang-tools-extra/clang-doc/BitcodeWriter.cpp
+2-3clang-tools-extra/clang-doc/BitcodeWriter.h
+58-642 files

LLVM/project 9578642flang/lib/Evaluate type.cpp

Still fighting a clang-format issue.
DeltaFile
+4-3flang/lib/Evaluate/type.cpp
+4-31 files

LLVM/project 202c2c4clang/include/clang/CIR/Dialect/IR CIROps.td, clang/lib/AST ASTContext.cpp

Merge branch 'main' into users/rampitec/fix-i16-disasm-roundtrip
DeltaFile
+168-0clang/test/CIR/CodeGen/cleanup-conditional-with-wrapper-eh.cpp
+96-47clang/lib/AST/ASTContext.cpp
+38-78clang/include/clang/CIR/Dialect/IR/CIROps.td
+116-0clang/test/CIR/CodeGen/cleanup-conditional-with-wrapper.cpp
+85-0clang/lib/CIR/Dialect/IR/CIRDialect.cpp
+77-0clang/test/CIR/IR/invalid-assume.cir
+580-12575 files not shown
+1,343-36281 files

LLVM/project 9d1a9c7libcxx/test/libcxx/utilities/function.objects block.func.compile.pass.cpp

Add regression test
DeltaFile
+32-0libcxx/test/libcxx/utilities/function.objects/block.func.compile.pass.cpp
+32-01 files

LLVM/project 77e43ecclang/include/clang/AST ASTContext.h, clang/include/clang/Lex MacroBase.h

Associate documentation comments with macro definitions (#198452)
DeltaFile
+96-47clang/lib/AST/ASTContext.cpp
+67-0clang/test/ExtractAPI/macro_doc_comments.c
+37-23clang/tools/libclang/CIndex.cpp
+43-0clang/include/clang/Lex/MacroBase.h
+24-16clang/include/clang/AST/ASTContext.h
+37-0clang/test/Index/annotate-comments-macros.c
+304-8612 files not shown
+338-11018 files

LLVM/project db614d9polly/lib/CodeGen IslNodeBuilder.cpp, polly/test/CodeGen issue192208.ll

[Polly] Do not invalidate SCEV before codegen (#194677)

ScopInfo expects the state of the IR to reflect the state before
codegen. Invalidating ScalarEvolution/SCEVs has the effect that values
need to be reanalyzed, but this is not possible during codegen where the
CFG and SSA is not yet in a consistent state. That is, we rely on
ScalarEvolution to cache SCEVs from before the codegen phase. If
ScalarEvolution did not already do this, Polly would need to more
aggressively store SCEVs itself (in this case: `canSyntheziseInStmt`)
instead of asking ScalarEvolution.

The SCEV invalidation was introduced in
a61eda769890900903ee65278bf1ee07dfbd4ca5 which unfortunately does not
explain the issue it intends to fix. The added test case passes even
without the invalidation. In any case, SCEVs should represent the state
before codegen.

Fixes #192208
DeltaFile
+61-0polly/test/CodeGen/issue192208.ll
+0-5polly/lib/CodeGen/IslNodeBuilder.cpp
+61-52 files

LLVM/project 24a77c3flang/lib/Evaluate type.cpp

Fixing code formatting issue and added additional comments to code.
DeltaFile
+7-3flang/lib/Evaluate/type.cpp
+7-31 files

LLVM/project 90cd935llvm/lib/Transforms/Vectorize VPlan.h, llvm/test/Transforms/LoopVectorize first-order-recurrence-tail-folding.ll find-last-iv-sinkable-expr-tail-folding.ll

[VPlan] Transfer nuw from CanIV -> WideCanIV (#198802)

An nuw on a CanonicalIV recipe should transfer to a WideCanonicalIV
recipe directly.
DeltaFile
+11-11llvm/test/Transforms/LoopVectorize/VPlan/vplan-sink-scalars-and-merge.ll
+9-6llvm/lib/Transforms/Vectorize/VPlan.h
+7-7llvm/test/Transforms/LoopVectorize/VPlan/conditional-scalar-assignment-vplan.ll
+6-6llvm/test/Transforms/LoopVectorize/first-order-recurrence-tail-folding.ll
+6-6llvm/test/Transforms/LoopVectorize/find-last-iv-sinkable-expr-tail-folding.ll
+6-6llvm/test/Transforms/LoopVectorize/VPlan/first-order-recurrence-sink-replicate-region.ll
+45-4232 files not shown
+104-10038 files

LLVM/project 0f67999libc/config/baremetal config.json

Revert "[libc] Enable baremetal float printf using modular format" (#199114)

Reverts llvm/llvm-project#198900

This can cause build failures due to an error in the handling of
argument indices for `va_list` `printf` variants.
DeltaFile
+3-3libc/config/baremetal/config.json
+3-31 files

LLVM/project 1be3309clang/lib/CIR/CodeGen CIRGenExpr.cpp CIRGenFunction.h, clang/lib/CIR/Lowering/DirectToLLVM LowerToLLVM.cpp

[CIR] Implement getUndefRValue for scalar, complex, and aggregate (#198921)

NYI builtin and call paths in CIR were calling getUndefRValue but the
helper only reported "unsupported type for undef rvalue" and returned
null.  libcxx then hit follow-on failures (including scalar-conversion
crashes) on the same translation units that already had other NYI
diagnostics.

Implement the same three cases as classic CodeGen: #cir.undef for
scalar and complex, and an undef.agg.tmp stack slot for aggregates.
Lower cir.const #cir.undef to llvm.undef in DirectToLLVM so emit-llvm
does not assert in the constant op lowering.  builtin-undef-rvalue.cpp
covers the __builtin_reduce_or NYI stub path with CIR/LLVM/OGCG checks.
DeltaFile
+35-2clang/lib/CIR/CodeGen/CIRGenExpr.cpp
+19-0clang/test/CIR/CodeGenBuiltins/builtin-undef-rvalue.cpp
+12-0clang/lib/CIR/Lowering/DirectToLLVM/LowerToLLVM.cpp
+5-3clang/lib/CIR/CodeGen/CIRGenFunction.h
+71-54 files

LLVM/project 76e7621llvm/lib/Transforms/IPO InstrumentorConfigFile.cpp

Use lookup()
DeltaFile
+1-2llvm/lib/Transforms/IPO/InstrumentorConfigFile.cpp
+1-21 files

LLVM/project 260d413llvm/include/llvm/Transforms/IPO Instrumentor.h, llvm/lib/Transforms/IPO InstrumentorConfigFile.cpp

[llvm][Instrumentor] Fix non-determinism in Instrumentor

In InstrumentorStubPrinter the StringMap was being iterated over, which
broke the Instrumentation/Instrumentor/write_config.ll test under
LLVM_REVERSE_ITERATION builds. We can use a MapVector to ensure the
order is stable. We only need to update the test json ordering to match
the stable order for with and without LLVM_REVERSE_ITERATION.
DeltaFile
+27-27llvm/test/Instrumentation/Instrumentor/default_config.json
+7-6llvm/lib/Transforms/IPO/InstrumentorConfigFile.cpp
+2-1llvm/include/llvm/Transforms/IPO/Instrumentor.h
+36-343 files

LLVM/project ac1c77clibcxx/include/__functional function.h

Add missing annotatinos for Apple platforms

These seemed to be missed in #193045.
DeltaFile
+6-0libcxx/include/__functional/function.h
+6-01 files

LLVM/project 817aaablibcxx/include/__functional function.h

Remove _LIBCPP_DIAGNOSTIC macros
DeltaFile
+0-2libcxx/include/__functional/function.h
+0-21 files

LLVM/project 676ccb6clang/include/clang/CIR/Dialect/IR CIROps.td, clang/lib/CIR/Dialect/IR CIRDialect.cpp

[CIR] Lower __builtin_assume_dereferenceable (#197262)

`__builtin_assume_dereferenceable` was reported NYI by ClangIR. It's
heavily exercised by libcxx via `__memory/valid_range.h`, so most of
`<algorithm>` currently fails to compile under `-fclangir`.

Adds a `cir.assume_dereferenceable` op (pointer + pointer-sized
integer), emits it from CIRGenBuiltin, and lowers it to

```
call void @llvm.assume(i1 true) [ "dereferenceable"(ptr, i64) ]
```

which is what classic Clang's `Builder.CreateDereferenceableAssumption`
produces.

The size operand is widened/narrowed to `intptr_t` at the CIRGen layer
to match classic CodeGen's `IntPtrTy` conversion.

Tests cover the dynamic-size, constant-size, and narrow-integer-size
cases against CIR, CIR->LLVM, and OGCG.
DeltaFile
+35-75clang/include/clang/CIR/Dialect/IR/CIROps.td
+85-0clang/lib/CIR/Dialect/IR/CIRDialect.cpp
+77-0clang/test/CIR/IR/invalid-assume.cir
+57-0clang/test/CIR/IR/assume.cir
+51-3clang/test/CIR/CodeGenBuiltins/builtin-call.cpp
+8-35clang/lib/CIR/Lowering/DirectToLLVM/LowerToLLVM.cpp
+313-1133 files not shown
+345-1189 files

LLVM/project 4259d8blibcxx/include/__functional function.h

Remove _LIBCPP_DIAGNOSTIC macros
DeltaFile
+0-2libcxx/include/__functional/function.h
+0-21 files

LLVM/project 3293365llvm/test/MC/Disassembler/AMDGPU gfx9_vop3.txt gfx11_dasm_vop3.txt

[AMDGPU] Use shorter form for i16 operands

For 16-bit operands an inline constant is zero extended
which in particular allows to use FP constants. These
will have 16 bits of zeroes in the high half and FP16
value in the low 16 bits.

The patch changes semantics of the FP literal argument
used in i16 context in the asm parser to fp16.
DeltaFile
+228-228llvm/test/MC/Disassembler/AMDGPU/gfx9_vop3.txt
+200-200llvm/test/MC/Disassembler/AMDGPU/gfx11_dasm_vop3.txt
+200-200llvm/test/MC/Disassembler/AMDGPU/gfx12_dasm_vop3.txt
+194-194llvm/test/MC/Disassembler/AMDGPU/gfx10_vop3.txt
+144-144llvm/test/MC/Disassembler/AMDGPU/gfx10_vop3c.txt
+128-128llvm/test/MC/Disassembler/AMDGPU/gfx8_vop3c.txt
+1,094-1,09479 files not shown
+3,554-3,75385 files

LLVM/project b6a56c4lldb/source/ValueObject ValueObject.cpp, lldb/test/API/python_api/sbvalue_get_parent MyContainer_synthetic.py main.cpp

[lldb] Call SetSyntheticChildrenGenerated on GetSyntheticChildAtOffset (#198859)

Follow up to #197311 and based on the feedback on that PR.

One way a Python synthetic formatter can construct a child is with
`SBValue::GetSyntheticChildAtOffset`. However those values were are not
marked as having been generated by `SyntheticChildren`. This means the
previous PR (#197311) did not apply to them as would be expected. The
fix is to call `SetSyntheticChildrenGenerated(true)` on the child values
created in `GetSyntheticChildAtOffset`.

Assisted-by: claude (tests and review)
DeltaFile
+29-0lldb/test/API/python_api/sbvalue_get_parent/MyContainer_synthetic.py
+7-0lldb/test/API/python_api/sbvalue_get_parent/main.cpp
+5-1lldb/test/API/python_api/sbvalue_get_parent/TestSBValueGetParent.py
+1-0lldb/source/ValueObject/ValueObject.cpp
+42-14 files

LLVM/project a9f1813clang/include/clang/CIR/Dialect/IR CIROps.td, clang/test/CIR/CodeGenBuiltins builtin-bit.cpp

[CIR] Allow clz/ctz/popcount on u8 and u128 widths (#198911)

libcxx with `-fclangir` was rejecting `cir.clz`, `cir.ctz`, and
`cir.popcount` when the operand type is `!u8i` or `!u128i` — the
verifier only allowed 16/32/64-bit widths even though codegen already
emits the right `llvm.ctlz` / `llvm.cttz` / `llvm.ctpop` intrinsics for
those sizes.  That shows up heavily in the May 20 upstream-main libcxx
baseline (`verifier-rejects-pre-pass-ir` bucket).

Widen the TableGen width lists on the three ops to match `bitreverse`
(8 through 128). `builtin-bit.cpp` gains `popcountg` on `unsigned char`,
and `popcountg` / `clzg` / `ctzg` on `unsigned __int128` when
`__SIZEOF_INT128__` is 16, each with CIR/LLVM/OGCG checks.
DeltaFile
+61-0clang/test/CIR/CodeGenBuiltins/builtin-bit.cpp
+3-3clang/include/clang/CIR/Dialect/IR/CIROps.td
+64-32 files

LLVM/project 62da8f2llvm/lib/Transforms/Vectorize SLPVectorizer.cpp, llvm/test/Transforms/SLPVectorizer/X86 ordered-reduction-replaced.ll

[SLP] Use TrackedVals for trailing scalars in tryToReduceOrdered

The trailing scalar fold passed the original candidate value to
createOp instead of its tracked form. When the same scalar also
appears inside the vectorized window, vectorizeTree replaces its
scalar uses with an extractelement (the scalar is added to the
externally-used values list), so the original instruction is gone
by the time the trailing fold runs. createOp then builds an fadd
that references the stale, replaced scalar, producing invalid IR
or a crash.

Look up the candidate in TrackedVals to retrieve the current
(extractelement when applicable) value, matching the leading
scalar fold loop above.

Reviewers: 

Pull Request: https://github.com/llvm/llvm-project/pull/199109
DeltaFile
+23-0llvm/test/Transforms/SLPVectorizer/X86/ordered-reduction-replaced.ll
+2-2llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+25-22 files

LLVM/project 24c2c69llvm/utils instrumentor-config-wizard.py

[Instrumentor] Improve the config wizard script

This makes the config wizard script more generic as we grow
instrumentation opportunities. Better output, e.g., clear paths, are
also displayed now.

Prepared with Claude (AI) and tested by me afterwards.
DeltaFile
+267-153llvm/utils/instrumentor-config-wizard.py
+267-1531 files

LLVM/project a01ddddclang/lib/CIR/CodeGen CIRGenCleanup.cpp, clang/test/CIR/CodeGen cleanup-conditional-with-wrapper-eh.cpp cleanup-conditional-with-wrapper.cpp

[CIR] Fix a problem with hoisting allocas out of nested cleanup scopes (#199093)

A recent change to the code that hoists allocas out of a cleanup scope
introduced an assertion that triggers when we're trying to hoist an
alloca that is in a cleanup scope that is nested within the cleanup
scope we're processing. I didn't think that could happen, but it turns
out the LLVM code itself triggers it.

This change removes the assertion and updates the check for the alloca
being contained within the cleanup scope we're processing so that it can
handle the case with nested scopes.

Assisted-by: Cursor / claude-opus-4.7-thinking-xhigh
DeltaFile
+168-0clang/test/CIR/CodeGen/cleanup-conditional-with-wrapper-eh.cpp
+116-0clang/test/CIR/CodeGen/cleanup-conditional-with-wrapper.cpp
+6-15clang/lib/CIR/CodeGen/CIRGenCleanup.cpp
+290-153 files

LLVM/project 07363e4llvm/include/llvm/Transforms/IPO Instrumentor.h InstrumentorUtils.h, llvm/lib/Transforms/IPO Instrumentor.cpp InstrumentorUtils.cpp

[Instrumentor][FIX] Ensure we indicate changes properly.

We now indicate changes whenever we might have changed things even if
the filter will rule out instrumentation. The issue was that we need to
get the argument to check the filter and that process might create new
IR, e.g., a global variable containing the function name.
DeltaFile
+13-8llvm/lib/Transforms/IPO/Instrumentor.cpp
+4-2llvm/include/llvm/Transforms/IPO/Instrumentor.h
+5-1llvm/lib/Transforms/IPO/InstrumentorUtils.cpp
+1-1llvm/include/llvm/Transforms/IPO/InstrumentorUtils.h
+23-124 files

LLVM/project e9d88calibcxx/include/__iterator move_iterator.h access.h, libcxx/test/libcxx/diagnostics iterator.nodiscard.verify.cpp

[libc++][iterator] Applied `[[nodiscard]]` (#172200)

`[[nodiscard]]` should be applied to functions where discarding the
return value is most likely a correctness issue.

- https://libcxx.llvm.org/CodingGuidelines.htm
- https://wg21.link/iterators

Also moves the test to the correct location:
`libcxx/test/libcxx/iterators/nodiscard.verify.cpp`

Towards #172124

---------

Co-authored-by: Hristo Hristov <zingam at outlook.com>
DeltaFile
+369-0libcxx/test/libcxx/iterators/nodiscard.verify.cpp
+23-18libcxx/include/__iterator/move_iterator.h
+0-38libcxx/test/libcxx/diagnostics/iterator.nodiscard.verify.cpp
+15-13libcxx/include/__iterator/access.h
+16-11libcxx/include/__iterator/reverse_iterator.h
+17-10libcxx/include/__iterator/reverse_access.h
+440-9013 files not shown
+490-13019 files