This is pre-cursor patch to enabling type units with DWARF5 acceleration
tables.
With this change it allows for entries to contain offsets directly, this
way type
units do not need to be preserved until .debug_names is written out.
Summary:
While this is technically a no-op for AMDGPU hardware, in cases where
the user would see fit to add an explicit wavefront sync on Nvidia
hardware, we should also inform the LLVM optimizer that this control
flow is convergent so we do not reorder blocks.
Summary:
This patch simply adds the `-fconvergent-functions` flag to the GPU
compilation. This is in relation to the behaviour of SIMT
architectures under divergence. With the flag, we assume every function
is convergent by default and rely on the compiler's divergence analysis
to transform it if possible.
Fixes: https://github.com/llvm/llvm-project/issues/63853
When a target sets LLVM_ENABLE_RUNTIMES, we should only generate proxy
targets for those runtimes rather than using the global list which may
contain runtimes that are not supported by that particular target.
If gpu.alloc has no asyn deependency ( in case if gpu.alloc has
hostShared allocation), create a new stream & synchronize. This PR is
follow up to #66401
While using dwarf5 `.debug_names` in internal large targets, we noticed
a performance issue (around 10 seconds delay) while `lldb-vscode` tries
to show `scopes` for a compile unit. Profiling shows the bottleneck is
inside `DebugNamesDWARFIndex::GetGlobalVariables` which linearly search
all index entries belongs to a compile unit.
This patch improves the performance by using the compile units list to
filter first before checking index entries. This significantly improves
the performance (drops from 10 seconds => under 1 second) in the split
dwarf situation because each compile unit has its own named index.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
Change cc2fbc648d7babbfa612f4f5eda3160212ef6ca7 introduced -Wdangling
warning, use temporaries to resolve.
llvm/lib/Transforms/Utils/CodeLayout.cpp:764:27: error: temporary whose address is used as value of local variable '[minDensity, maxDensity]' will be destroyed at the end of the full-expression [-Werror,-Wdangling]
764 | std::minmax(ChainPred->density(), ChainSucc->density());
llvm/lib/Transforms/Utils/CodeLayout.cpp:764:49: error: temporary whose address is used as value of local variable '[minDensity, maxDensity]' will be destroyed at the end of the full-expression [-Werror,-Wdangling]
764 | std::minmax(ChainPred->density(), ChainSucc->density());
This effectively reverts f912d21e673b0
This was originally done for consistency with RISCVISD::ADD_LO so that
all nodes were emitted as RISCVISD nodes.
I've received feedback a couple times that its not worth it. So I'm
putting it back.
MipsIncomingValueHandler::assignCustomValue should return 1 instead of
2. The return value is the number of additional ArgLocs being consumed.
It's assumed that at least 1 is consumed.
Correct the LocVT used for the spill when there are no registers left.
It should be f64 instead of i32. This allows a workaround to be removed
in the SelectionDAG path.
Maps to
[`CXCursor_ConceptDecl`](ee8524087c/clang/include/clang-c/Index.h (L2716)),
added in ee8524087c78a673fcf5486ded69ee597a85e0f1.
Without this I get this error on my codebase which uses C++20 concept
decls:
```
ValueError: Unknown template argument kind 604
```
Summary:
This version is required to support the 'activemask' feature which is
used for certain features, such as reductions. This ties the
implementation of the DeviceRTL roughly to the features provided by the
CUDA 9.0 release, which should be sufficienly old as to not cause
problems since this is a minor version jump that corresponds to the
release of `sm_53`.
During constant evaluation when value-initializing a class if the base
class was default-initialized it would undue the previously
zero-initialized class members. This fixes the way we handle default
initialization to avoid initializing over an already initialized member
to an indeterminate value.
Fixes: https://github.com/llvm/llvm-project/issues/69890
This patch changes the way plugin objects used with Scripted Interfaces
are created.
Instead of implementing a different SWIG method to create the object for
every scripted interface, this patch makes the creation more generic by
re-using some of the ScriptedPythonInterface templated Dispatch code.
This patch also improves error handling of the object creation by
returning an `llvm::Expected`.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
With the recent change 98c90a13 (ISel: introduce vector ISD::LRINT,
ISD::LLRINT; custom RISCV lowering), it is now possible to scalarize
llvm.lrint and llvm.llrint with a trivial change to VectorUtils. In
preparation for this change, and the corresponding test update, add a
negative test for lrint and llrint.
To follow-up on a06be8a (SLP/RISCV: add negative test for lrint), add a
negative test for llvm.llrint as well, and increase the coverage to
cover vectors of length 2, 4, and 8, and the i32 variant of lrint, in
preparation to get SLPVectorizer to vectorize both lrint and llrint.
This is now possible with the recent change 98c90a1 (ISel: introduce
vector ISD::LRINT, ISD::LLRINT; custom RISCV lowering).
The implementation of -Wzero-as-null-pointer-constant was done before
the following fix has been committed to GCC:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=752e7593b0f19af233a0b7e72daab8413662b605;hp=298434c916c14e8adca2cab8a746aee29038c5b3
As a result, clang and gcc diverge on the use of `__null` and,
consequently, on the use of `NULL` on systems like Linux/macOS where
`NULL` is defined as `__null`.
This is a problem for compatibility between gcc and clang, particularly
for code bases that support C++98 or for single-source libraries that
are implemented in C, but compiled as C++ via inclusion into a C++
translation unit. Code like this can not be changed to use `nullptr`, as
it needs to maintain compatibility with C before C23 or C++ before
C++11, but warns on the use of `NULL` in clang.
The warning `Wzero-as-null-pointer-constant` is still useful with this
change, as it allows to change `0` to `NULL`, which fixes
gcc warnings and helps the reader distinguish between pointers and
non-pointers. Users who require a full C++11 modernization pass can
still use clang-tidy for that purpose.
Summary:
This function needs `void` as the arguments to be ABI compatbile with
what is actually defined. This is enforced when doing CUDA separable
linking of the runtime.
Summary:
This accidentally was a dangling reference and caused issues when
actually used. Make sure that the memory is saved before the job is
created.
Linalg currently has these named ops:
* `matmul`
* `matvec`
* `vecmat`
* `batch_matmul`
* `batch_matvec`
But it does not have:
* `batch_vecmat`
This PRs adds that for consistency, and I have a short-term need for it
( https://github.com/openxla/iree/issues/15158 ), so not having this
would cause some contortion on my end.
Second half of the tests switching to opaque pointers. All are the
target related tests.
Removes mlir/test/Target/LLVMIR/openmp-reduction-typed-pointers.mlir,
since this seems to be added to test the typed pointers and probably not
needed anymore.
Teach SelectionDAG::salvageDebugInfo() to salvage debug information for
ADD nodes where the RHS is non-constant.
In the first try, the test case used the MIR output that was produced by
using -stop-before=sparc-isel. Running -start-before=sparc-isel on that
output resulted in the following verifier error with EXPENSIVE_CHECKS:
"Function has NoVRegs property but there are VReg operands".
In this re-attempt the test case has been rewritten to a .ll test by
extracting the IR from the original MIR file. The test still starts
before sparc-isel.
Co-authored-by: Mikael Holmen <mikael.holmen@ericsson.com>
Aggressive inlining might produce huge functions with >10K of basic
blocks. Since BFI treats _all_ blocks and jumps as "hot" having
non-negative (but perhaps small) weight, the current implementation can
be slow, taking minutes to produce an layout. This change introduces a
few modifications that significantly (up to 50x on some instances)
speeds up the computation. Some notable changes:
- reduced the maximum chain size to 512 (from the prior 4096);
- introduced MaxMergeDensityRatio param to avoid merging chains with
very different densities;
- dropped a couple of params that seem unnecessary.
Looking at some "offline" metrics (e.g., the number of created
fall-throughs), there shouldn't be problems; in fact, I do see some
metrics go up. But it might be hard/impossible to measure perf
difference for such small changes. I did test the performance clang-14
binary and do not record a perf or i-cache-related differences.
My 5 benchmarks, with ext-tsp runtime (the lower the better) and
"tsp-score" (the higher the better).
**Before**:
- benchmark 1:
num functions: 13,047
reordering running time is 2.4 seconds
score: 125503458 (128.3102%)
- benchmark 2:
num functions: 16,438
reordering running time is 3.4 seconds
score: 12613997277 (129.7495%)
- benchmark 3:
num functions: 12,359
reordering running time is 1.9 seconds
score: 1315881613 (105.8991%)
- benchmark 4:
num functions: 96,588
reordering running time is 7.3 seconds
score: 89513906284 (100.3413%)
- benchmark 5:
num functions: 1
reordering running time is 372 seconds
score: 21292505965077 (99.9979%)
- benchmark 6:
num functions: 71,155
reordering running time is 314 seconds
score: 29795381626270671437824 (102.7519%)
**After**:
- benchmark 1:
reordering running time is 2.2 seconds
score: 125510418 (128.3130%)
- benchmark 2:
reordering running time is 2.6 seconds
score: 12614502162 (129.7525%)
- benchmark 3:
reordering running time is 1.6 seconds
score: 1315938168 (105.9024%)
- benchmark 4:
reordering running time is 4.9 seconds
score: 89518095837 (100.3454%)
- benchmark 5:
reordering running time is 4.8 seconds
score: 21292295939119 (99.9971%)
- benchmark 6:
reordering running time is 104 seconds
score: 29796710925310302879744 (102.7565%)
Summary:
The `llvm_omp_target_dynamic_shared_alloc` prototype in `omp.h`
accidentally left the void argument unspecified. This created unintended
code when called from the C language, causing some `nvlink` failures in
certain scenarios.
After PR#69417, lowering for combined constructs was updated to adhere
to OpenACC 3.3, section 2.11: `A private or reduction clause on a
combined construct is treated as if it appeared on the loop construct.`
However, the second part of that paragraph notes `In addition, a
reduction clause on a combined construct implies a copy clause`. Since
the acc dialect decomposes combined constructs, it is important to
distinguish between the case where an explicit data clause is required
(as noted in section 2.6.2) and the case where an implicit data action
must be generated by compiler.
