[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.
[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.
[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.
[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.
[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
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.
[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.
[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.
[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.
[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.
[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)
[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.
[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
[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.
[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
[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.
[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>
