TargetMachine::shouldAssumeDSOLocal currently implies dso_local for such definitions.
Since clang -fno-pic add the dso_local specifier, we don't need to special case.
TargetMachine::shouldAssumeDSOLocal currently implies dso_local for such definitions.
Adding explicit dso_local makes these tests align with the clang -fno-pic behavior
and allow the removal of the TargetMachine::shouldAssumeDSOLocal special case.
TargetMachine::shouldAssumeDSOLocal currently implies dso_local for such definitions.
Adding explicit dso_local makes these tests align with the clang -fno-pic behavior
and allow the removal of the TargetMachine::shouldAssumeDSOLocal special case.
Split tiny_model.ll to tiny-model-{static,pic}.ll
TargetMachine::shouldAssumeDSOLocal currently implies dso_local for such definitions.
Adding explicit dso_local makes these tests align with the clang -fno-pic behavior
and allow the removal of the TargetMachine::shouldAssumeDSOLocal special case.
Due to the unfortunate way the bug could only be triggered when reading SPRG[0-3] into a register lower than %r4 with the "mfsprg %rX, 0" syntax, the tests did not detect it.
(It could not be triggered for "mfsprg0, %r2" because that pattern was already in the table, so the earlier "correct" match took effect)
As a canary, add an intentionally ambiguous "mfsprg 2, 2" and "mtsprg 2, 2" check that would have caught the problem.
Reviewed By: ZhangKang
Differential Revision: https://reviews.llvm.org/D86489
The matching for intrinsic names is forgiving about types in the
name being absent or wrong. Once the intrinsic is parsed its
name will remangled to include the real types.
This commit fixes the names to have at least enough correct types
so that the name used in the test is a prefix of the canonical name.
The big missing part is the type for the VL parameter which changes
size between rv32 and rv64.
While I was in here I noticed that we were missing some tests for
double on rv32 so I fixed that by copying from rv64 and fixing up
the VL argument type.
I don't know if there's some way this changes what the vectorizers
may produce for reductions, but I have added test coverage with
3567908 and 5ced712 to show that both passes already have bugs in
this area. Hopefully this does not make things worse before we can
really fix it.
This will hopefully fix the build not becoming clean when using Ninja
1.9+. Ninja 1.9 enabled high-resolution time stamps, but pax doesn't
correctly set high-resolution timestamps on its output.
See https://github.com/nico/hack/blob/master/notes/copydir.md for a
detailed writeup of problem and alternatives.
TargetMachine::shouldAssumeDSOLocal currently implies dso_local for such definitions.
Adding explicit dso_local makes these tests align with the clang -fpic behavior
and allow the removal of the TargetMachine::shouldAssumeDSOLocal special case.
Rewrite preemption.ll to dsolocal-static.ll and dsolocal-pic.ll, and add
"PIC Level" metadata.
There are functions that the linker is able to automatically
deduplicate, we do not outline from these functions by default. This
allows for outlining from those functions.
Tests:
llvm/test/Transforms/IROutliner/outlining-odr.ll
Reviewers: jroelofs, paquette
Differential Revision: https://reviews.llvm.org/D87309
This is no-functional-change-intended (AFAIK, we can't
isolate this difference in a regression test).
That's because the callers should be setting the IRBuilder's
FMF field when creating the reduction and/or setting those
flags after creating. It doesn't make sense to override this
one flag alone.
This is part of a multi-step process to clean up the FMF
setting/propagation. See PR35538 for an example.
X-inseltpoison.ll is a copy of X.ll with insertelement/shufflevector's
placeholder replaced with poison.
This commit removes a few redundant functions which do not contain any
shufflevector/insertelement.
As mentioned in D93793, there are quite a few places where unary `IRBuilder::CreateShuffleVector(X, Mask)` can be used
instead of `IRBuilder::CreateShuffleVector(X, Undef, Mask)`.
Let's update them.
Actually, it would have been more natural if the patches were made in this order:
(1) let them use unary CreateShuffleVector first
(2) update IRBuilder::CreateShuffleVector to use poison as a placeholder value (D93793)
The order is swapped, but in terms of correctness it is still fine.
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D93923
This patch adds support for select form of and/or.
Currently there is an ongoing effort for moving towards using `select a, b, false` instead of `and i1 a, b` and
`select a, true, b` instead of `or i1 a, b` as well.
D93065 has links to relevant changes.
Alive2 proof: (undef input was disabled due to timeout :( )
- and: https://alive2.llvm.org/ce/z/AgvFbQ
- or: https://alive2.llvm.org/ce/z/KjLJyb
Differential Revision: https://reviews.llvm.org/D93935
This simplifies TargetMachine::shouldAssumeDSOLocal and and gives frontend the
decision to use dso_local. For LLVM synthesized functions/globals, they may lose
inferred dso_local but such optimizations are probably not very useful.
Note: the hasComdat() condition in canBenefitFromLocalAlias (D77429) may be dead now.
(llvm/CodeGen/X86/semantic-interposition-comdat.ll)
(Investigate whether we need test coverage when Fuchsia C++ ABI is clearer)
Since some values can be swift errors, we need to make sure that we
correctly propagate the parameter attributes.
Tests found at:
llvm/test/Transforms/IROutliner/outlining-swift-error.ll
Reviewers: jroelofs, paquette
Recommit of: 71867ed5e6606a93f0c1413f205afe3bb16317fe
Differential Revision: https://reviews.llvm.org/D87742
The x86_amx is used for AMX intrisics. <256 x i32> is bitcast to x86_amx when
it is used by AMX intrinsics, and x86_amx is bitcast to <256 x i32> when it
is used by load/store instruction. So amx intrinsics only operate on type x86_amx.
It can help to separate amx intrinsics from llvm IR instructions (+-*/).
Thank Craig for the idea. This patch depend on https://reviews.llvm.org/D87981.
Differential Revision: https://reviews.llvm.org/D91927
This change adds '--write-if-changed' flag to llvm-elfabi tool. When
enabled, llvm-elfabi will not overwrite the existing file if the
content of the file will not be changed, which preserves the
timestamp.
Differential Revision: https://reviews.llvm.org/D92902
