LLVM/project 7ed5bbeclang/lib/Parse ParseOpenMP.cpp, clang/test/SemaOpenMP gh197162.c invalid-clause-on-directive.c

[Clang][OpenMP] Skip Sema actions for invalid assumption clauses (#212822)

Do not call the Sema actions for absent, contains, and nullary assumption
clauses after the parser has diagnosed that the clause is not allowed on the
current directive.

Add assertions documenting that these Sema actions must only receive clauses
allowed on the current directive, and add tests covering all affected clause
kinds.

Fixes #212780.
DeltaFile
+25-0clang/test/SemaOpenMP/invalid-clause-on-directive.c
+6-4clang/lib/Parse/ParseOpenMP.cpp
+0-6clang/test/SemaOpenMP/gh197162.c
+31-103 files

LLVM/project b56f40ellvm/lib/Transforms/Vectorize SLPVectorizer.cpp, llvm/lib/Transforms/Vectorize/SLPVectorizer SLPUtils.h SLPUtils.cpp

[𝘀𝗽𝗿] initial version

Created using spr 1.3.7
DeltaFile
+292-123llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+20-32llvm/test/Transforms/SLPVectorizer/X86/reassociate-ops.ll
+28-0llvm/lib/Transforms/Vectorize/SLPVectorizer/SLPUtils.cpp
+15-0llvm/lib/Transforms/Vectorize/SLPVectorizer/SLPUtils.h
+2-4llvm/test/Transforms/SLPVectorizer/X86/supernode.ll
+357-1595 files

LLVM/project 036af90llvm/lib/Target/Hexagon HexagonExpandCondsets.cpp, llvm/test/CodeGen/Hexagon dont-predicate-debug.mir

[Hexagon] Avoid predicating debug instructions (#212917)

The change is made in HexagonExpandCondsets::(predicate) function. The
debug instructions are not predicable as they cannot be separated into
conditional branches. So while predicating instructions in a machine
basic block if we encounter any debug instructions we need to skip these
instructions and continue with other instructions.

The scan that collects the registers defined and used between the
definition of the source register and the conditional transfer bailed
out as soon as it saw a non-virtual register operand, which a DBG_VALUE
can have. The transfer was then left as an unconditional A2_asrh plus an
A2_tfrf instead of being folded into a single predicated A4_pasrhf, so
again the generated code differed depending on whether debug info was
enabled.

Co-authored-by: Chandana Sinderikeri <csinderi at qti.qualcomm.com>
DeltaFile
+59-0llvm/test/CodeGen/Hexagon/dont-predicate-debug.mir
+5-0llvm/lib/Target/Hexagon/HexagonExpandCondsets.cpp
+64-02 files

LLVM/project 2a4acc4llvm/test/Transforms/SLPVectorizer/X86 reassociate-ops.ll

[SLP][NFC]Add extra test for alt opcodes vectorization with copyables, NFC



Reviewers: 

Pull Request: https://github.com/llvm/llvm-project/pull/213538
DeltaFile
+70-0llvm/test/Transforms/SLPVectorizer/X86/reassociate-ops.ll
+70-01 files

LLVM/project f383699llvm/test/Transforms/SLPVectorizer/X86 reassociate-ops.ll

[𝘀𝗽𝗿] initial version

Created using spr 1.3.7
DeltaFile
+70-0llvm/test/Transforms/SLPVectorizer/X86/reassociate-ops.ll
+70-01 files

LLVM/project eee7c2dllvm/docs ORCv2.md, llvm/include/llvm/ExecutionEngine/Orc COFFAutoImportGenerator.h

[ORC] Add AutoImportGenerator for COFF dllimport auto-import (#203914)

On Windows/COFF, a dllimport call is emitted as an indirect call through
an `__imp_` IAT slot (`callq *__imp_bar(%rip)`), and even a direct call
to a library function is expected to bind to a thunk supplied by an
import library. Today a JIT client must produce those import libraries
themselves. `AutoImportGenerator` synthesizes them on demand instead.

Bound to a single dynamic library via `AutoImportGenerator::Load(ES,
ObjLinkingLayer, "/path/to/lib.dll")`.
For each referenced export `X`, lazily synthesizes an `__imp_X` pointer
slot holding `X`'s address in the library plus an `X` thunk that jumps
through it, so both `__imp_`-mediated and direct references resolve.


The library's export table is the authority: a name the library does not
export is left unresolved, so the link fails exactly as a static link
against the corresponding import library would (no silent invention of
symbols).

    [23 lines not shown]
DeltaFile
+178-0llvm/unittests/ExecutionEngine/Orc/COFFAutoImportGeneratorTest.cpp
+132-0llvm/lib/ExecutionEngine/Orc/COFFAutoImportGenerator.cpp
+112-0llvm/include/llvm/ExecutionEngine/Orc/COFFAutoImportGenerator.h
+60-3llvm/tools/llvm-jitlink/llvm-jitlink.cpp
+39-0llvm/docs/ORCv2.md
+3-3llvm/lib/ExecutionEngine/JITLink/COFF_x86_64.cpp
+524-65 files not shown
+532-611 files

LLVM/project 9a19c77clang/lib/Driver/ToolChains NetBSD.h NetBSD.cpp, clang/test/Driver netbsd.cpp

[clang][Driver] Fix libc++ include path on NetBSD (#212716)

`clang++` defaults to `-stdlib=libc++` on NetBSD. When building with
both `clang` and `libcxx` included, the freshly built `clang++` fails to
find `<__config_site>`:

```
In file included from /usr/include/strings.h:68:
In file included from bin/../include/c++/v1/string.h:57:
bin/../include/c++/v1/__config:13:10: fatal
error: '__config_site' file not found
   13 | #include <__config_site>
      |          ^~~~~~~~~~~~~~~
```

The file is present in `include/<triplet>/c++/v1`, but that isn't
searched by default. NetBSD has its own version of addLibCxxIncludePaths
which misses that directory.


    [9 lines not shown]
DeltaFile
+0-21clang/lib/Driver/ToolChains/NetBSD.cpp
+8-0clang/test/Driver/netbsd.cpp
+0-3clang/lib/Driver/ToolChains/NetBSD.h
+0-0clang/test/Driver/Inputs/install_tree_with_libcxx/lib/.keep
+0-0clang/test/Driver/Inputs/install_tree_with_libcxx/include/c++/v1/.keep
+0-0clang/test/Driver/Inputs/install_tree_with_libcxx/bin/.keep
+8-246 files

LLVM/project 4695d91llvm/include/llvm/ExecutionEngine/Orc/RTBridge Calls.h, llvm/include/llvm/ExecutionEngine/Orc/RTBridge/SPS Calls.h

[ORC] Generalize RTBridge Callers to any runtime function (#213526)

An RTBridge Caller is a controller-side handle for calling a function in
the runtime. Until now the abstraction assumed every such function was a
trampoline -- a runtime function whose job is to invoke *another*
function at an address the controller supplies (run-as-main, run-as-int,
etc.) -- so every Caller carried a dedicated ExecutorAddr parameter for
that target.

Generalize Callers to call runtime functions of any shape. Invoking a
supplied target is now just one kind of call, with the target address an
ordinary leading argument rather than a built-in parameter: e.g.
MainCaller becomes Caller<int64_t(ExecutorAddr, ArrayRef<std::string>)>.

The SPS signatures already led with an SPSExecutorAddr for the target,
so this is a pure interface change -- the SPS wrappers and all call
sites are unaffected. It lets Callers model runtime functions that do
the work themselves, such as the memory-access wrappers, rather than
only those that dispatch to another function.
DeltaFile
+15-16llvm/include/llvm/ExecutionEngine/Orc/RTBridge/Calls.h
+8-9llvm/include/llvm/ExecutionEngine/Orc/RTBridge/SPS/Calls.h
+23-252 files

LLVM/project 29a956eclang/include/clang/Options Options.td, clang/lib/CodeGen CGOpenMPRuntimeGPU.cpp

[offload][OpenMP] Add atomic cross-team reductions (#209298)

Regular cross-team reductions have two phases: the intra-team reduction
and the inter-team reduction. Atomic cross-team reductions replace the
second phase with a atomic instruction which is used by the main thread
of each team to directly fold the result of the intra-team reduction
into the final result. Since this requires a combination of "data type"
and "combine operation" for which an atomic instruction is available,
only some (but very common) reductions can be transformed to atomic
reductions. In cases where multiple reductions are performed on the same
construct, the atomic path is only taken if all reductions can be
transformed. Otherwise, we fall back to the regular cross-team reduction
using a buffer with per-team slots. This is not strictly necessary, but
hybrid reductions would induce more complexity with questionable
benefit.

Selecting an atomic path might not be the best option for every
situation, which is why it is not enabled by default. Instead, it can be
enabled via `-fopenmp-target-atomic-reduction`. Note that enabling the

    [17 lines not shown]
DeltaFile
+107-2clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+90-0clang/test/OpenMP/target_teams_atomic_reduction_codegen.cpp
+64-0offload/test/offloading/xteam_atomic_reduction_usm.cpp
+32-0llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+18-0clang/test/Driver/openmp-target-atomic-reduction-flag.c
+9-0clang/include/clang/Options/Options.td
+320-26 files not shown
+340-212 files

LLVM/project b1e21e2llvm/lib/Transforms/Vectorize VPlanTransforms.h VPlanTransforms.cpp, llvm/test/Transforms/LoopVectorize find-last-iv-sinkable-expr.ll

[VPlan] Handle step where sign cannot be determined optimizeFindIVRed. (#213450)

optimizeFindIVReductions uses the step to determine if min or max is
needed. Bail out if the direction of the step cannot be determined via
SCEV.

Fixes https://github.com/llvm/llvm-project/issues/213424
DeltaFile
+112-0llvm/test/Transforms/LoopVectorize/find-last-iv-sinkable-expr.ll
+25-12llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
+3-1llvm/lib/Transforms/Vectorize/VPlanTransforms.h
+140-133 files

LLVM/project 4e924a6lldb/source/Expression IRExecutionUnit.cpp

[lldb] std::move unique_ptrs, rather than calling .release. (#213525)

These .release() calls are legacy from the std::auto_ptr to
std::unique_ptr transition.
DeltaFile
+2-2lldb/source/Expression/IRExecutionUnit.cpp
+2-21 files

LLVM/project e096d2flld/COFF Chunks.h Driver.cpp, lld/test/COFF arm64x-tls.s

[LLD][COFF] Replace ARM64EC TLS directory chunks with native chunks when available (#212845)

On ARM64X targets, CRT provides separate TLS directory chunks, expecting
the linker to sort it out. TLS directory uses _tls_start and _tls_end
symbols to reference .tls section. Those symbols use section sorting to
ensure that they are emitted at the start and end of .tls section, but that's
not enough when we have two separate chunks for views: only one of them
can really be the first one. Following MSVC, merge those chunks instead so
that both symbol tables point to the same chunk.

Additionally apply the same logic to _tls_used and _tls_index. This
allows entire TLS directory to be shared between EC and native views. To
achieve that, CRT additionally needs to mark each TLS callback with
-arm64xsameaddress. This matches how MSVC linker and libraries work, but
it requires EC and native views to use the same set of TLS callbacks. We
may emit separate TLS directories in the future to make it more robust.
DeltaFile
+121-0lld/test/COFF/arm64x-tls.s
+24-3lld/COFF/Driver.cpp
+2-1lld/COFF/Chunks.h
+147-43 files

LLVM/project 012e06bllvm/test/CodeGen/AArch64 extractvector-of-load.mir, llvm/test/CodeGen/AArch64/GlobalISel icmp-flags.mir fold-global-offsets-target-features.mir

[AArch64][GlobalISel] Update a number of combiner tests to concrete types. NFC (#213522)
DeltaFile
+112-112llvm/test/CodeGen/AArch64/GlobalISel/form-bitfield-extract-from-and.mir
+62-62llvm/test/CodeGen/AArch64/GlobalISel/opt-overlapping-and.mir
+61-61llvm/test/CodeGen/AArch64/GlobalISel/fold-global-offsets.mir
+32-32llvm/test/CodeGen/AArch64/GlobalISel/fold-global-offsets-target-features.mir
+18-18llvm/test/CodeGen/AArch64/GlobalISel/icmp-flags.mir
+14-14llvm/test/CodeGen/AArch64/extractvector-of-load.mir
+299-2995 files not shown
+337-33711 files

LLVM/project a3da102libc CMakeLists.txt, libc/cmake/caches gpu.cmake

[libc] Use llvm-link approach to create libc bitcode library for GPU targets (#210662)
DeltaFile
+35-30libc/cmake/modules/LLVMLibCLibraryRules.cmake
+6-8libc/startup/gpu/CMakeLists.txt
+4-0libc/CMakeLists.txt
+3-0llvm/runtimes/CMakeLists.txt
+1-1libc/lib/CMakeLists.txt
+1-1libc/cmake/caches/gpu.cmake
+50-406 files

LLVM/project 45e4b0ellvm/lib/CodeGen/GlobalISel CallLowering.cpp, llvm/test/CodeGen/AArch64/GlobalISel ret-vec-promote.ll vec-param.ll

[AArch64][GlobalISel] Update extended scalar type to integer. (#213457)

This updates a number of scalar types in CallLowering to use integer.
DeltaFile
+44-44llvm/test/CodeGen/AArch64/GlobalISel/vec-param.ll
+8-8llvm/test/CodeGen/AArch64/GlobalISel/ret-vec-promote.ll
+6-6llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call.ll
+4-4llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-function-args.v2i65.ll
+4-4llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
+2-2llvm/test/CodeGen/AMDGPU/GlobalISel/function-returns.v2i65.ll
+68-686 files

LLVM/project 6c83817llvm/lib/Transforms/Scalar ConstraintElimination.cpp, llvm/test/Transforms/ConstraintElimination ne-tightening.ll srem.ll

[ConstraintElim] Add facts for SREM. (#213453)

Add facts for SRem, if operands are known to be non-negative.

Add signed bounds for `srem x, n`:

  * `x s>= 0`  =>  result s>= 0  and  result s<= x
  * `n s>  0`  =>  result s<=  n

Alive2 Proofs: https://alive2.llvm.org/ce/z/e-zoAP

Compile-time is in the noise

https://llvm-compile-time-tracker.com/compare.php?from=60f965b1f62c0c77bcdb2997ea9bb6603aa0d002&to=ebc652af5700d569884e27812d33735d604990a1&stat=instructions:u

InstCombine already has a similar fold, but with more limited reasoning.
It does not trigger any changes on
https://github.com/dtcxzyw/llvm-opt-benchmark-nightly/pull/841


    [10 lines not shown]
DeltaFile
+26-2llvm/lib/Transforms/Scalar/ConstraintElimination.cpp
+8-16llvm/test/Transforms/ConstraintElimination/srem.ll
+1-2llvm/test/Transforms/ConstraintElimination/ne-tightening.ll
+35-203 files

LLVM/project 50782acllvm/lib/Target/Sparc SparcInstr64Bit.td, llvm/test/CodeGen/SPARC bswap.ll

[SPARC] Add patterns for i64->i32 and i64->i16 BSWAP-STOREs (#210483)

The lack of those is causing instruction selection to fail.

Also, for completeness, add variants of extending/truncating ops for
LOAD-BSWAP pairs too.

(cherry picked from commit 7afc89970fc3675d77e92aa091b65c078cacdcff)
DeltaFile
+501-0llvm/test/CodeGen/SPARC/bswap.ll
+5-0llvm/lib/Target/Sparc/SparcInstr64Bit.td
+506-02 files

LLVM/project ab8ca57.github/workflows release-binaries.yml

workflows/release-binaries: Move environment declaration to upload job (#212687)

This is the only job that actually needs to use the environment secrets,
so the environment must be declared. We were using secrets in the
prepare job to do a permissions check, but this is unnecessary, because
that job does not do anything that is security sensitive.

Only the upload job needs to have these permission checks and these are
already included in the upload-release-artifact composite action.

(cherry picked from commit 02bde0716776a742164941e05cb026e750763b04)
DeltaFile
+3-11.github/workflows/release-binaries.yml
+3-111 files

LLVM/project 774cc4f.github/workflows release-sources.yml

workflows/release-sources: Pass release-version to upload-release-artifacts (#212660)

This was omitted from a8ccd42ab23af6848929a638cd6b099953c7e491.

(cherry picked from commit 22308c4c51c49bb7ea562d83d0d564cc922d9c21)
DeltaFile
+1-0.github/workflows/release-sources.yml
+1-01 files

LLVM/project edb9efbclang/lib/CodeGen CodeGenModule.cpp, clang/test/CodeGen/AArch64 ptrauth-function-attributes-synthetic.c

[clang][llvm][AArch64] Set hardening fn attrs on synthetic functions (#211013)

Compiler-synthesized functions such as `__llvm_gcov_writeout`,
`__llvm_gcov_reset` and `__llvm_gcov_init` were previously never
receiving the AArch64 hardening function attributes (ptrauth-returns,
ptrauth-auth-traps, ptrauth-indirect-gotos and
aarch64-jump-table-hardening) since the attributes were only emitted by
Clang and gated by `PointerAuthOptions` structure's corresponding
fields. See `setPointerAuthFnAttributes` and
`initPointerAuthFnAttributes` member functions of `TargetCodeGenInfo`.

This patch resolves this in the same manner as #83153 does for several
other attributes. Particularly, Clang now emits corresponding 4 module
flags (conditionally on whether the related feature is enabled) with Max
behavior, and LLVM's `Function::createWithDefaultAttr` derives the
matching function attributes from them. Max behavior with conditional
emission is safe because none of these features affect ABI, so promoting
an absent flag on module merge cannot break compatibility.

(cherry picked from commit 2f8eb5b4be3eba5c7f58470d6538d00df53a55fc)
DeltaFile
+64-0llvm/test/Instrumentation/AddressSanitizer/ptrauth-module-flags-aarch64.ll
+53-0clang/test/CodeGen/AArch64/ptrauth-function-attributes-synthetic.c
+39-0llvm/test/Transforms/GCOVProfiling/ptrauth-module-flags-aarch64.ll
+26-0clang/lib/CodeGen/CodeGenModule.cpp
+4-0llvm/lib/IR/Function.cpp
+186-05 files

LLVM/project 222ff59llvm/lib/Target/RISCV RISCVISelLowering.cpp, llvm/test/CodeGen/RISCV/rvv vector-interleave-fixed.ll

[RISCV] Fix incorrect lowering of VECTOR_INTERLEAVE on fixed vectors (#212642)

This is the sibling patch of #207254, as it turns out VECTOR_INTERLEAVE
has the same problem on fixed vectors as well.

Instead of converting individual operands into scalable vectors, this
patch puts each of the operands directly onto stack using the fixed
vector version of segmented store intrinsics, before loading them back.

---------

Co-authored-by: Luke Lau <luke at igalia.com>
(cherry picked from commit ff9b99207b5d4ec73554defc1e3c1ac50f8ff1d8)
DeltaFile
+690-1,062llvm/test/CodeGen/RISCV/rvv/vector-interleave-fixed.ll
+24-27llvm/lib/Target/RISCV/RISCVISelLowering.cpp
+714-1,0892 files

LLVM/project 5971217llvm/lib/DWARFLinker/Classic DWARFLinker.cpp, llvm/test/tools/dsymutil/X86 keep-enumerators.test

[DWARFLinker] Keep DW_TAG_enumerator children of a live enumeration_type (#212849)

Swift allows functions inside enums:

  enum Foo: Int {
    case bar = 0

    func baz() { ... }
    }

  DW_TAG_enumeration_type  "Foo"
    DW_TAG_enumerator        "bar"
    DW_TAG_subprogram        "baz"  DW_AT_declaration
  ...
  DW_TAG_subprogram  DW_AT_low_pc(...)  DW_AT_specification -> "baz"

dieNeedsChildrenToBeMeaningful() did not list DW_TAG_enumeration_type,
so the parent walk skipped the enum's children.


    [4 lines not shown]
DeltaFile
+160-0llvm/test/tools/dsymutil/X86/keep-enumerators.test
+1-0llvm/lib/DWARFLinker/Classic/DWARFLinker.cpp
+161-02 files

LLVM/project 5d61005llvm/docs ReleaseNotes.md

[docs] Add BOLT release notes
DeltaFile
+14-0llvm/docs/ReleaseNotes.md
+14-01 files

LLVM/project e1d649allvm/lib/Transforms/Scalar LowerAtomicPass.cpp, llvm/test/Transforms/LowerAtomic atomic-load-store-elementwise.ll

[LowerAtomic] Clear elementwise flag when lowering atomic load (#213401)

The lower atomic pass demotes atomic loads to non atomic by
calling setAtomic(NotAtomic), but left the elementwise flag untouched.
Since elementwise is only valid on atomic operations, this produced a
non-atomic elementwise load, which the verifier rejects with "non-atomic
load cannot be elementwise".

Reference: https://github.com/llvm/llvm-project/pull/204556
DeltaFile
+12-0llvm/test/Transforms/LowerAtomic/atomic-load-store-elementwise.ll
+1-0llvm/lib/Transforms/Scalar/LowerAtomicPass.cpp
+13-02 files

LLVM/project ffc32callvm/lib/Transforms/InstCombine InstCombineLoadStoreAlloca.cpp, llvm/test/Transforms/InstCombine atomic.ll

[InstCombine] Don't change the type of elementwise atomic loads (#213414)

Skip load type canonicalization for elementwise atomic loads, which
would
otherwise drop the vector type and produce an invalid scalar elementwise
load.

Reference: https://github.com/llvm/llvm-project/pull/204556
DeltaFile
+11-0llvm/test/Transforms/InstCombine/atomic.ll
+3-0llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
+14-02 files

LLVM/project e18c3eallvm/test/Analysis/BlockFrequencyInfo irreducible.ll

[test] Add irreducible CFGs with closed-form block frequencies (#213492)

The functions here have irreducible control flow, but none of them pins
down how mass is divided among the entries of an irreducible region.

Add four cases whose exact frequencies follow from the branch weights:

- equalrows: all blocks share one successor distribution; 5:3:2.
- selfloops: self edges of differing probability; ignoring them, each
block
  splits evenly between the other two; 8:5:5.
- unequalrows: symmetric non-header successors, differing header row;
8:3:3.
- nonentry: a member of the region that is not an entry, so its mass is
never
  adjusted; 6:4:3.

BFI computes the first two exactly and the last two not. #213488 will
show up as a diff.
DeltaFile
+106-0llvm/test/Analysis/BlockFrequencyInfo/irreducible.ll
+106-01 files

LLVM/project 8d292a7llvm/lib/ExecutionEngine/Orc InProcessEPC.cpp SelfExecutorProcessControl.cpp, llvm/lib/ExecutionEngine/Orc/TargetProcess OrcRTBootstrap.cpp

[ORC] Remove EPC runAsVoidFunction/runAsIntFunction methods (#213265)

Remove runAsVoidFunction and runAsIntFunction from
ExecutorProcessControl and all its implementations, along with the
now-unused RunAs{Void,Int}FunctionWrapperName bootstrap symbols and
SimpleRemoteEPC's corresponding address fields. Their only in-tree
users, COFFPlatform and COFFVCRuntimeSupport, now use
rt::sps::Int32VoidCaller and rt::sps::Int32Int32Caller.

runAsMain is likewise routed through rt::sps::MainCaller's controller-
interface symbol, so it is looked up under the same orc_rt_ci_sps_* name
the target-process bootstrap registers.

This is a step towards decoupling the ExecutorProcessControl interface
from SPS serialization.
DeltaFile
+14-11llvm/lib/ExecutionEngine/Orc/COFFVCRuntimeSupport.cpp
+3-21llvm/lib/ExecutionEngine/Orc/SimpleRemoteEPC.cpp
+10-9llvm/lib/ExecutionEngine/Orc/TargetProcess/OrcRTBootstrap.cpp
+9-4llvm/lib/ExecutionEngine/Orc/COFFPlatform.cpp
+0-12llvm/lib/ExecutionEngine/Orc/SelfExecutorProcessControl.cpp
+0-11llvm/lib/ExecutionEngine/Orc/InProcessEPC.cpp
+36-687 files not shown
+36-11113 files

LLVM/project 6a3d4d9llvm/lib/Target/CSKY/AsmParser CSKYAsmParser.cpp, llvm/lib/Target/CSKY/MCTargetDesc CSKYELFStreamer.h CSKYTargetStreamer.h

[CSKY] Emit build attributes in assembly output (#213507)

Fixes CodeGen/CSKY/fpu-abi-attribute.ll, failing since #212975.

emitTargetAttributes is implemented only by CSKYTargetELFStreamer, so
llc -filetype=asm drops every .csky_attribute directive. Move it to
CSKYTargetStreamer, as ARM and RISC-V do.
DeltaFile
+171-1llvm/lib/Target/CSKY/MCTargetDesc/CSKYTargetStreamer.cpp
+0-164llvm/lib/Target/CSKY/MCTargetDesc/CSKYELFStreamer.cpp
+13-0llvm/test/MC/CSKY/default-build-attributes.s
+5-1llvm/lib/Target/CSKY/AsmParser/CSKYAsmParser.cpp
+3-2llvm/lib/Target/CSKY/MCTargetDesc/CSKYTargetStreamer.h
+0-3llvm/lib/Target/CSKY/MCTargetDesc/CSKYELFStreamer.h
+192-1716 files

LLVM/project 2450b7emlir/examples/standalone/python CMakeLists.txt, mlir/python CMakeLists.txt

[MLIR][Python] Drop the LLVMSupport link dependency from the python extensions (#213509)

Follow-up to #180986, which completed the series started in #178290: it switched the last python bindings off the C++ LLVM APIs and dropped `LLVMSupport` from the support library in `AddMLIRPython.cmake`. But the per extension `PRIVATE_LINK_LIBS LLVMSupport` in `mlir/python/CMakeLists.txt` was missed, so the dependency is still there for every extension module.

Assisted by: Claude
DeltaFile
+0-39mlir/python/CMakeLists.txt
+0-2mlir/examples/standalone/python/CMakeLists.txt
+0-412 files

LLVM/project 3a09d9fmlir/cmake/modules AddMLIRPython.cmake

Update AddMLIRPython.cmake

restore doc string
DeltaFile
+1-3mlir/cmake/modules/AddMLIRPython.cmake
+1-31 files