LLVM/project 0f86cb3mlir/docs/Dialects/OpenMPDialect _index.md ODS.md

[MLIR][OpenMP][Docs] Reorganize 'omp' dialect documentation (NFC) (#107232)

This patch creates a handwritten main documentation page for the OpenMP
dialect linking to the ODS-generated one as a sub-section.

This new page can be extended to better describe overall design
decisions of the dialect rather than relying exclusively on
documentation generated automatically from ODS descriptions. After some
investigation, there seem to be a few main ways we could structure
dialect documentation to allow the introduction of possibly extensive
handwritten text.
- Create a top-level OpenMPDialect.td file that includes the
auto-generated one. This is what the `acc` dialect currently does, but
it results in the addition of two equal TOCs. It would be possible to
move the `include` before all handwritten sections so that the page
would have a single TOC, but I believe moving general descriptions to
the end of the document would hurt readability. Also keeping the section
order without introducing a second TOC would mean the TOC would be
inserted somewhere halfway through the page, which isn't useful.

    [14 lines not shown]
DeltaFile
+16-0mlir/docs/Dialects/OpenMPDialect/_index.md
+3-0mlir/docs/Dialects/OpenMPDialect/ODS.md
+19-02 files

LLVM/project dbdf843clang/test/Driver riscv-cpus.c, clang/test/Misc/target-invalid-cpu-note riscv.c

[RISCV] Add Syntacore SCR7 processor definition (#108406)

Syntacore SCR7 is a high-performance Linux-capable RISC-V processor
core.
The core has rv64imafdcv_zba_zbb_zbc_zbs_zkn march.
Overview: https://syntacore.com/products/scr7

Scheduling model will be added in a subsequent PR.

---------

Co-authored-by: Dmitrii Petrov <dmitrii.petrov at syntacore.com>
Co-authored-by: Anton Afanasyev <anton.afanasyev at syntacore.com>
Co-authored-by: Elena Lepilkina <elena.lepilkina at syntacore.com>
DeltaFile
+26-0clang/test/Driver/riscv-cpus.c
+19-0llvm/lib/Target/RISCV/RISCVProcessors.td
+2-0clang/test/Misc/target-invalid-cpu-note/riscv.c
+1-0llvm/docs/ReleaseNotes.rst
+48-04 files

LLVM/project feac761llvm/lib/CodeGen/GlobalISel LegalizerHelper.cpp, llvm/lib/Target/AArch64 AArch64InstrInfo.td

[GlobalISel][AArch64] Add G_FPTOSI_SAT/G_FPTOUI_SAT (#96297)

This is an implementation of the saturating fp to int conversions for
GlobalISel. On AArch64 the converstion instrctions work this way,
producing saturating results. LegalizerHelper::lowerFPTOINT_SAT is
ported from SDAG.

AArch64 has a lot of existing tests for fptosi_sat, covering a wide
range of types. I have tried to make most of them work all at once, but
a few fall back due to other missing features such as f128 handling for
min/max.
DeltaFile
+4,636-2,363llvm/test/CodeGen/AArch64/fptosi-sat-vector.ll
+3,650-1,844llvm/test/CodeGen/AArch64/fptoui-sat-vector.ll
+728-316llvm/test/CodeGen/AArch64/fptosi-sat-scalar.ll
+540-227llvm/test/CodeGen/AArch64/fptoui-sat-scalar.ll
+150-0llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
+48-6llvm/lib/Target/AArch64/AArch64InstrInfo.td
+9,752-4,75613 files not shown
+9,861-4,75719 files

LLVM/project 7e5fe3elldb/packages/Python/lldbsuite/test bench.py, lldb/test/API/benchmarks/expression TestRepeatedExprs.py TestExpressionCmd.py

[lldb][test] Remove benchmark API tests (#108629)

These benchmarks don't get run as part of the regular API test-suite.
And I'm not aware of any CI running this. Also, I haven't quite managed
to actually run them locally using the `bench.py` script. It looks like
these are obsolete, so I'm proposing to remove the infrastructure around
it entirely.

If anyone does know of a use for these do let me know.
DeltaFile
+0-131lldb/test/API/benchmarks/expression/TestRepeatedExprs.py
+0-122lldb/test/API/benchmarks/turnaround/TestCompileRunToBreakpointTurnaround.py
+0-78lldb/test/API/benchmarks/startup/TestStartupDelays.py
+0-77lldb/packages/Python/lldbsuite/test/bench.py
+0-74lldb/test/API/benchmarks/expression/TestExpressionCmd.py
+0-69lldb/test/API/benchmarks/stepping/TestSteppingSpeed.py
+0-55113 files not shown
+0-92519 files

LLVM/project 9e9b117lldb/examples/synthetic libcxx.py, lldb/source/Plugins/Language/CPlusPlus LibCxxUnorderedMap.cpp LibCxx.cpp

[lldb] Support new libc++ __compressed_pair layout (#96538)

This patch is in preparation for the `__compressed_pair` refactor in
https://github.com/llvm/llvm-project/pull/76756.

This is mostly reviewable now. With the new layout we no longer need to
unwrap the `__compressed_pair`. Instead, we just need to look for child
members. E.g., to get to the underlying pointer of `std::unique_ptr` we
no longer do,
```
GetFirstValueOfCXXCompressedPair(GetChildMemberWithName("__ptr_"))

```
but instead do
```
GetChildMemberWithName("__ptr_")
```

We need to be slightly careful because previously the

    [4 lines not shown]
DeltaFile
+104-64lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
+63-22lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+43-29lldb/source/Plugins/Language/CPlusPlus/LibCxxList.cpp
+20-20lldb/source/Plugins/Language/CPlusPlus/LibCxxVector.cpp
+29-10lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
+22-6lldb/examples/synthetic/libcxx.py
+281-1512 files not shown
+284-1558 files

LLVM/project 8d89f83llvm/test/CodeGen/RISCV/rvv vfma-vp.ll floor-vp.ll

[RISCV] Add some missing VP zvfhmin test coverage. NFC

We're also missing coverage for the vp_reduce_* nodes, but they
currently crash with zvfhmin. It looks like they're getting expanded
instead of promoted.
DeltaFile
+8,355-1,124llvm/test/CodeGen/RISCV/rvv/vfma-vp.ll
+539-188llvm/test/CodeGen/RISCV/rvv/floor-vp.ll
+539-188llvm/test/CodeGen/RISCV/rvv/ceil-vp.ll
+9,433-1,5003 files

LLVM/project 27c8338libcxx/include __hash_table string, libcxx/include/__memory compressed_pair.h unique_ptr.h

[libc++] Replace `__compressed_pair` with `[[no_unique_address]]` (#76756)

This significantly simplifies the code, improves compile times and
improves the object layout of types using `__compressed_pair` in the
unstable ABI. The only downside is that this is extremely ABI sensitive
and pedantically breaks the ABI for empty final types, since the address
of the subobject may change. The ABI of the whole object should not be
affected.

Fixes #91266
Fixes #93069
DeltaFile
+56-137libcxx/include/__memory/compressed_pair.h
+87-68libcxx/include/__hash_table
+73-74libcxx/include/string
+71-53libcxx/include/__memory/unique_ptr.h
+93-28libcxx/test/libcxx/utilities/memory/util.smartptr/util.smartptr.shared/libcxx.control_block_layout.pass.cpp
+42-47libcxx/include/vector
+422-40721 files not shown
+631-67327 files

LLVM/project e16ec9bllvm/lib/CodeGen/SelectionDAG SelectionDAG.cpp

[SelectionDAG] Do not build illegal nodes with users (#108573)

When we build a node with illegal type which has a user, it's possible
that it can end up being processed by the DAG combiner later before it's
removed, which can trigger an assert expecting the types to be legalized
already.
DeltaFile
+7-4llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
+7-41 files

LLVM/project 57b50a9utils/bazel/llvm-project-overlay/llvm BUILD.bazel

[bazel] port 2ae968a0d9fb61606b020e898d884c82dd0ed8b5
DeltaFile
+1-1utils/bazel/llvm-project-overlay/llvm/BUILD.bazel
+1-11 files

LLVM/project cab4c10mlir/lib/AsmParser Parser.cpp

[mlir][AsmParser] Avoid use of moved value (#108789)

'std::string detailData' is moved in the innermost loop of a 2-layer
loop, but is written to throughout the whole duration of the 2-layer
loop.

After move, std::string is in an unspecified state
(implementation-dependent).

Avoid using a moved value, as it incurs undefined behavior.
DeltaFile
+4-3mlir/lib/AsmParser/Parser.cpp
+4-31 files

LLVM/project 6784202llvm/include/llvm/MCA/HardwareUnits ResourceManager.h, llvm/lib/MCA/HardwareUnits ResourceManager.cpp

[MCA][ResourceManager] Fix a bug in the instruction issue logic. (#108386)

Before this patch, the pipeline selection logic in
ResourceManager::issueInstruction() didn't know how to correctly handle
instructions which consume multiple partially overlapping resource
groups. In some cases (like the test case from #108157), the inability
to correctly allocate resources on instruction issue was leading to
crashes.

The presence of multiple partially overlapping groups complicates the
selection process by introducing extra constraints. For those cases, the
issue logic now prioritizes groups which are more constrained than
others.

Fixes #108157
DeltaFile
+91-0llvm/test/tools/llvm-mca/X86/Znver4/partially-overlapping-group-resources.s
+84-3llvm/lib/MCA/HardwareUnits/ResourceManager.cpp
+28-3llvm/include/llvm/MCA/HardwareUnits/ResourceManager.h
+203-63 files

LLVM/project 50d3543clang/lib/CodeGen CGBuiltin.cpp

Revert "[clang][codegen] Fix possible crash when setting TBAA metadata on FP …"

This reverts commit a56ca1a0fb248c6f38b5841323a74673748f43ea.
DeltaFile
+3-4clang/lib/CodeGen/CGBuiltin.cpp
+3-41 files

LLVM/project b7e51b4llvm/lib/IR Function.cpp, llvm/lib/Transforms/Utils SCCPSolver.cpp

[IPSCCP] Infer attributes on arguments (#107114)

During inter-procedural SCCP, also infer attributes on arguments, not
just return values. This allows other non-interprocedural passes to make
use of the information later.
DeltaFile
+45-22llvm/lib/Transforms/Utils/SCCPSolver.cpp
+8-8llvm/test/Transforms/SCCP/ip-constant-ranges.ll
+7-7llvm/test/Transforms/SCCP/ip-ranges-casts.ll
+7-3llvm/test/Transforms/SCCP/pointer-nonnull.ll
+3-3llvm/test/Transforms/SCCP/ip-ranges-phis.ll
+5-0llvm/lib/IR/Function.cpp
+75-439 files not shown
+91-5215 files

LLVM/project b29c5b6llvm/lib/Transforms/Vectorize LoopVectorize.cpp VPlanTransforms.cpp

[NFC][LoopVectorize] Dont pass LLVMContext to VPTypeAnalysis constructor (#108540)

We already pass a Type object into the VPTypeAnalysis constructor, which
can be used to obtain the context. While in the same area it also made
sense to avoid passing the context into the VPTransformState and
VPCostContext constructors.
DeltaFile
+5-12llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+5-6llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
+4-4llvm/lib/Transforms/Vectorize/VPlan.h
+2-4llvm/lib/Transforms/Vectorize/VPlan.cpp
+3-2llvm/lib/Transforms/Vectorize/VPlanAnalysis.h
+19-285 files

LLVM/project 6d3f6c2clang/include/clang/AST RecursiveASTVisitor.h

[RecursiveASTVisitor] Do not inline TraverseStmt (NFC) (#107601)

As things are now, this reduces size of clang bootstrapped with ThinLTO
by 0.3% and reduces thin link time by 0.3%. More importantly, it avoids
a large regression once https://github.com/llvm/llvm-project/pull/107114
is merged. Without this change, there would be a 0.4% regression in code
size and 4% (!) regression in thin link time. There is no impact on
run-time performance.
DeltaFile
+4-2clang/include/clang/AST/RecursiveASTVisitor.h
+4-21 files

LLVM/project dfa5429llvm/include/llvm/CodeGen TargetRegisterInfo.h TargetSubtargetInfo.h, llvm/lib/CodeGen InitUndef.cpp

[InitUndef] Enable the InitUndef pass on non-AMDGPU targets (#108353)

The InitUndef pass works around a register allocation issue, where undef
operands can be allocated to the same register as early-clobber result
operands. This may lead to ISA constraint violations, where certain
input and output registers are not allowed to overlap.

Originally this pass was implemented for RISCV, and then extended to ARM
in #77770. I've since removed the target-specific parts of the pass in
#106744 and #107885. This PR reduces the pass to use a single
requiresDisjointEarlyClobberAndUndef() target hook and enables it by
default. The hook is disabled for AMDGPU, because overlapping
early-clobber and undef operands are known to be safe for that target,
and we get significant codegen diffs otherwise.

The motivating case is the one in arm64-ldxr-stxr.ll, where we were
previously incorrectly allocating a stxp input and output to the same
register.
DeltaFile
+27-0llvm/test/CodeGen/AArch64/init-undef.mir
+3-11llvm/lib/CodeGen/InitUndef.cpp
+0-14llvm/lib/Target/ARM/ARMBaseRegisterInfo.h
+0-13llvm/include/llvm/CodeGen/TargetRegisterInfo.h
+6-6llvm/include/llvm/CodeGen/TargetSubtargetInfo.h
+0-7llvm/lib/Target/ARM/ARMSubtarget.h
+36-516 files not shown
+51-6212 files

LLVM/project 961bc37compiler-rt/test/asan/TestCases global-overflow.cpp large_func_test.cpp

[ASan][test] XFAIL global-overflow.cpp etc. on SPARC (#108200)

When enabling ASan testing on SPARC as per PR #107405, two tests `FAIL`
in similar ways as detailed in Issue #108194: at `-O1` and above, one
line of the stacktrace lacks the line number info, causing the tests to
`FAIL`. I could trace this to `clang` generating incomplete line number
info; `g++` gets this right.

To avoid this, this patch `XFAIL`s the affected tests on SPARC.

Tested on `sparcv9-sun-solaris2.11`.
DeltaFile
+3-0compiler-rt/test/asan/TestCases/global-overflow.cpp
+3-0compiler-rt/test/asan/TestCases/large_func_test.cpp
+6-02 files

LLVM/project d76966ecompiler-rt/test/sanitizer_common/TestCases sanitizer_coverage_trace_pc_guard-dso.cpp sanitizer_coverage_trace_pc_guard.cpp

[sanitizer_common][test] Disable sanitizer_coverage_trace_pc_guard.cp… (#108206)

…p etc. on SPARC

When enabling ASan testing on SPARC as per PR #107405, two tests `FAIL`:
```
  SanitizerCommon-asan-sparc-SunOS :: sanitizer_coverage_trace_pc_guard-dso.cpp
  SanitizerCommon-asan-sparc-SunOS :: sanitizer_coverage_trace_pc_guard.cpp

```
The issue is the same in both cases:
```
WARNING: No coverage file for projects/compiler-rt/test/sanitizer_common/asan-sparc-SunOS/Output/sanitizer_coverage_trace_pc_guard.cpp.tmp
WARNING: No coverage file for sanitizer_coverage_trace_pc_guard.cpp.tmp.22766.sancov
ERROR: No valid coverage files given.

```
Checking the file with `sancov -print` reveals `Wrong magic:
4294967090`. There seems to be an endianess bug somewhere, since the

    [4 lines not shown]
DeltaFile
+2-1compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_trace_pc_guard-dso.cpp
+1-1compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_trace_pc_guard.cpp
+3-22 files

LLVM/project 9b237b4compiler-rt/lib/asan asan_posix.cpp

[ASan] Disable InstallAtForkHandler on Linux/sparc64 (#108542)

When SPARC Asan testing is enabled by PR #107405, many Linux/sparc64
tests just hang like
```
#0  0xf7ae8e90 in syscall () from /usr/lib32/libc.so.6
#1  0x701065e8 in __sanitizer::FutexWait(__sanitizer::atomic_uint32_t*, unsigned int) ()
    at compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:766
#2  0x70107c90 in Wait ()
    at compiler-rt/lib/sanitizer_common/sanitizer_mutex.cpp:35
#3  0x700f7cac in Lock ()
    at compiler-rt/lib/asan/../sanitizer_common/sanitizer_mutex.h:196
#4  Lock ()
    at compiler-rt/lib/asan/../sanitizer_common/sanitizer_thread_registry.h:98
#5  LockThreads ()
    at compiler-rt/lib/asan/asan_thread.cpp:489
#6  0x700e9c8c in __asan::BeforeFork() ()
    at compiler-rt/lib/asan/asan_posix.cpp:157
#7  0xf7ac83f4 in ?? () from /usr/lib32/libc.so.6

    [11 lines not shown]
DeltaFile
+5-1compiler-rt/lib/asan/asan_posix.cpp
+5-11 files

LLVM/project cf2122cclang/lib/Headers arm_acle.h, clang/test/CodeGen arm_acle.c

[Clang][ARM] Make CRC and DSP intrinsics always available. (#107417)

Both feature has target feature so can be checked if the usage is valid.
DeltaFile
+73-3clang/test/CodeGen/arm_acle.c
+18-21clang/lib/Headers/arm_acle.h
+91-242 files

LLVM/project 1bd72c4llvm/lib/CodeGen FinalizeISel.cpp, llvm/lib/Target/X86 X86ISelLowering.cpp

[X86] Avoid generating nested CALLSEQ for TLS pointer function arguments

When a pointer to thread-local storage is passed in a function call,
ISel first lowers the call and wraps the resulting code in CALLSEQ
markers. Afterwards, to compute the pointer to TLS, a call to retrieve
the TLS base address is generated and then wrapped in a set of CALLSEQ
markers. If the latter call is inserted into the call sequence of the
former call, this leads to nested call frames, which are illegal and
lead to errors in the machine verifier.

This patch avoids surrounding the call to compute the TLS base address
in CALLSEQ markers if it is already surrounded by such markers. It
relies on zero-sized call frames being represented in the call frame
size info stored in the MachineBBs.

Fixes #45574 and #98042.
DeltaFile
+30-0llvm/test/CodeGen/X86/tls-function-argument.ll
+9-0llvm/lib/Target/X86/X86ISelLowering.cpp
+6-0llvm/lib/CodeGen/FinalizeISel.cpp
+45-03 files

LLVM/project 9cad0b2llvm/include/llvm/CodeGen MachineFrameInfo.h MachineBasicBlock.h, llvm/lib/CodeGen MachineFrameInfo.cpp PrologEpilogInserter.cpp

[CodeGen] Compute call frame sizes instead of storing them in MachineBBs

Previously, we would need to update stored call frame sizes whenever a
MachineBB with a call sequence is split or call frame instructions are
moved. By recomputing them instead, this change avoids the need for
keeping track of the call frame sizes throughout transformations. It
also fixes several cases where updates of call frame sizes were missing.

The overhead according to the compile time tracker is < +0.03% executed
instructions on all CT benchmarks.

This also allows distinguishing a zero-sized call frame from no open
call frame, which is helpful to avoid nested CALLSEQs (which are illegal
and cause machine verifier errors).
DeltaFile
+148-0llvm/lib/CodeGen/MachineFrameInfo.cpp
+80-0llvm/include/llvm/CodeGen/MachineFrameInfo.h
+7-27llvm/lib/CodeGen/PrologEpilogInserter.cpp
+0-26llvm/lib/Target/X86/X86FrameLowering.cpp
+0-22llvm/include/llvm/CodeGen/MachineBasicBlock.h
+0-21llvm/lib/CodeGen/TargetInstrInfo.cpp
+235-9617 files not shown
+243-20723 files

LLVM/project e88b7fflld/ELF SyntheticSections.cpp Writer.cpp

[ELF] Move InStruct into Ctx. NFC

Ctx was introduced in March 2022 as a more suitable place for such
singletons.

llvm/Support/thread.h includes <thread>, which transitively includes
sstream in libc++ and uses ios_base::in, so we cannot use `#define in ctx.sec`.

`symtab, config, ctx` are now the only variables using
LLVM_LIBRARY_VISIBILITY.
DeltaFile
+102-102lld/ELF/SyntheticSections.cpp
+49-48lld/ELF/Writer.cpp
+42-35lld/ELF/InputSection.cpp
+58-0lld/ELF/Config.h
+28-26lld/ELF/Relocations.cpp
+0-38lld/ELF/SyntheticSections.h
+279-24918 files not shown
+370-33624 files

LLVM/project 339282dclang/include/clang/StaticAnalyzer/Core/PathSensitive SValBuilder.h, clang/lib/StaticAnalyzer/Checkers MallocChecker.cpp

[analyzer] Refactor MallocChecker to use `BindExpr` in `evalCall` (#106081)

PR refactors `MallocChecker` to not violate invariant of `BindExpr`,
which should be called only during `evalCall` to avoid conflicts.

To achieve this, most of `postCall` logic was moved to `evalCall` with
addition return value binding in case of processing of allocation
functions. Check functions prototypes was changed to use `State` with
bound return value.

`checkDelim` logic was left in `postCall` to avoid conflicts with
`StreamChecker` which also evaluates `getline` and friends.

PR also introduces breaking change in the unlikely case when the
definition of an allocation function (e.g. `malloc()`) is visible: now
checker does not try to inline allocation functions and assumes their
initial semantics.

Closes #73830
DeltaFile
+237-135clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
+0-35clang/test/Analysis/malloc-interprocedural.c
+12-10clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+0-17clang/test/Analysis/NewDelete-checker-test.cpp
+6-6clang/include/clang/StaticAnalyzer/Core/PathSensitive/SValBuilder.h
+2-2clang/test/Analysis/NewDelete-intersections.mm
+257-2054 files not shown
+261-21110 files

LLVM/project d779685lldb/source/Commands CommandObjectLog.cpp, lldb/source/Core Module.cpp

[lldb] Nits on uses of llvm::raw_string_ostream (NFC) (#108745)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923bae884ba395ad084d for further reference )

* Don't call raw_string_ostream::flush(), which is essentially a no-op.
* Avoid unneeded calls to raw_string_ostream::str(), to avoid excess
indirection.
DeltaFile
+0-9lldb/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
+4-4lldb/source/Commands/CommandObjectLog.cpp
+2-4lldb/tools/lldb-dap/DAP.cpp
+3-3lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
+1-4lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+2-2lldb/source/Core/Module.cpp
+12-2631 files not shown
+35-6937 files

LLVM/project 4fdccd3llvm/utils/gn/secondary/llvm/lib/Transforms/Instrumentation BUILD.gn, llvm/utils/gn/secondary/llvm/lib/Transforms/Utils BUILD.gn

[gn build] Port 2ae968a0d9fb
DeltaFile
+0-1llvm/utils/gn/secondary/llvm/lib/Transforms/Instrumentation/BUILD.gn
+1-0llvm/utils/gn/secondary/llvm/lib/Transforms/Utils/BUILD.gn
+1-12 files

LLVM/project 2ae968allvm/include/llvm/Transforms Instrumentation.h, llvm/include/llvm/Transforms/Instrumentation GCOVProfiler.h

[Instrumentation] Move out to Utils (NFC) (#108532)

Utility functions have been moved out to Utils. Minor opportunity to
drop the header where not needed.
DeltaFile
+209-0llvm/include/llvm/Transforms/Utils/Instrumentation.h
+0-209llvm/include/llvm/Transforms/Instrumentation.h
+123-0llvm/lib/Transforms/Utils/Instrumentation.cpp
+0-121llvm/lib/Transforms/Instrumentation/Instrumentation.cpp
+1-1llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+1-1llvm/include/llvm/Transforms/Instrumentation/GCOVProfiler.h
+334-33222 files not shown
+352-35328 files

LLVM/project f9d7257llvm/lib/Transforms/IPO AttributorAttributes.cpp, llvm/test/CodeGen/AMDGPU aa-as-infer.ll

[Attributor] Take the address space from addrspacecast directly

If the value to be analyzed is directly from addrspacecast, we take the source
address space directly. This is to improve the case where in
`AMDGPUPromoteKernelArgumentsPass`, the kernel argument is promoted by
insertting an addrspacecast directly from a generic pointer. However, during the
analysis, the underlying object will be the generic pointer, instead of the
addrspacecast, thus the inferred address space is the generic one, which is not
ideal.
DeltaFile
+48-14llvm/lib/Transforms/IPO/AttributorAttributes.cpp
+33-0llvm/test/CodeGen/AMDGPU/aa-as-infer.ll
+81-142 files

LLVM/project e6eae2bmlir/lib/Bindings/Python IRAttributes.cpp, mlir/lib/Target/LLVMIR ModuleImport.cpp

[𝘀𝗽𝗿] initial version

Created using spr 1.3.4
DeltaFile
+3-3mlir/lib/Transforms/ViewOpGraph.cpp
+2-2mlir/lib/Bindings/Python/IRAttributes.cpp
+2-2mlir/lib/Target/LLVMIR/ModuleImport.cpp
+2-2mlir/lib/Target/SPIRV/Serialization/Serializer.cpp
+2-1mlir/lib/Tools/mlir-opt/MlirOptMain.cpp
+2-1mlir/lib/Tools/PDLL/Parser/Parser.cpp
+13-117 files not shown
+20-1813 files

LLVM/project 20e76a5llvm/lib/Transforms/IPO AttributorAttributes.cpp, llvm/test/CodeGen/AMDGPU aa-as-infer.ll

[Attributor] Take the address space from addrspacecast directly

If the value to be analyzed is directly from addrspacecast, we take the source
address space directly. This is to improve the case where in
`AMDGPUPromoteKernelArgumentsPass`, the kernel argument is promoted by
insertting an addrspacecast directly from a generic pointer. However, during the
analysis, the underlying object will be the generic pointer, instead of the
addrspacecast, thus the inferred address space is the generic one, which is not
ideal.
DeltaFile
+48-14llvm/lib/Transforms/IPO/AttributorAttributes.cpp
+35-0llvm/test/CodeGen/AMDGPU/aa-as-infer.ll
+83-142 files