An instruction that is "always uniform" is so even if it occurs in an
irreducible cycle. The output produced by such an instruction may depend on the
implementation defined cycle hierarchy, but that does not affect the uniformity
of the output. In other words, an "always uniform" instruction is uniform even
if it is not m-converged.
Reviewed By: ruiling, ronlieb
Differential Revision: https://reviews.llvm.org/D145572
Unlimited polymorphic entities can have an intrinsic dynamic type. Update the
code of extends_type_of to compare the CFI_type in these case.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D145722
Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179
When this patch lands any downstream users with custom LLVM conversion passes not yet using opaque pointers will start either experiencing assertions being triggered, null pointer dereferences or at the very least verifier errors. These can be either fixed by switching to opaque pointers or simply disabling opaque pointers in both pass options of any upstream conversion passes and any uses of `LLVMTypeConverter` via the `LowerToLLVMOptions`.
Users using just MLIRs conversion passes to the LLVM Dialect should not experience any change in functionality except when inspecting the output from the passes.
Differential Revision: https://reviews.llvm.org/D145585
In the assertion enabled mode we will test if the computed linkage of
Declaration is consistent with the cached linkage. But we shouldn't
compuate it if we have cached linkage in the release modes.
This moves the LoadFPImmArr array to the cpp file. Being in the header
meant it was duplicated in every translation unit that includes the
header.
Move the 2 functions that use the array out of line.
This change improves FS discriminators in the following ways:
(1) use call-stack debug information in the the to generate
discriminators: the same (src/line) DILs can now have same
discriminator value if they come from different call-stacks.
This effectively increases the usable discriminator values
for each round of FS discriminator pass.
(2) don't generate the FS discriminator for meta instructions
(i.e. instructions not emitted). This reduces the number
discriminators conflicts (for the case we run out of discriminator
bits for that pass).
(3) use less expensive hashing of xxHash64.
These improvements should bring better performance for FSAFDO
and they should be used by default. But this change creates
incompatible FS discriminators. For the iterative profile users,
they might see a performance drop in the first release with
this change (due to the fact that the profiles have the old
discriminators and the compiler uses the new discriminator).
We have measured that this is not more than 1.5% on several
benchmarks. Note the degradation should be gone in the second
release and one should expect a performance gain over the binary
without this change.
One possible solution to the iterative profile issue would be
separating discriminators for profile-use and the ones emitted to
the binary. This would require a mechanism to allow two sets of
discriminators to be maintained and then phasing out the first
approach. This is too much churn in the compiler and the
performance implications do not seem to be worth the effort.
Instead, we put the changes under an option so iterative profile
users can do a gradual rollout of this change. We will make the
option default value to true in a later patch and eventually
purge this option from the code base.
Differential Revision: https://reviews.llvm.org/D145171
Close https://github.com/llvm/llvm-project/issues/61064.
The root cause of the issue is that we will deserilize some declarations
eagerly when reading the BMI. However, many declarations in the BMI are
not necessary for the importer. So it wastes a lot of time.
/data/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:138:9: error: out-of-line definition of 'Fuzzer' does not match any declaration in 'fuzzer::Fuzzer'
Fuzzer::Fuzzer(UserCallback CB, InputCorpus &Corpus, MutationDispatcher &MD,
^~~~~~
/data/llvm-project/compiler-rt/lib/fuzzer/FuzzerInternal.h:35:10: note: type of 4th parameter of member declaration does not match definition ('fuzzer::FuzzingOptions &' vs 'const fuzzer::FuzzingOptions &')
FuzzingOptions &Options);
^
1 error generated.
This change allows using fp8 pointers when exporting to LLVM, because we anyway export them as opaque pointers, however full support of fp8 types is not yet implemented on the LLVM side.
Differential Revision: https://reviews.llvm.org/D143008
Currently HIP toolchain uses Driver::GetTemporaryDirectory to
create a temporary directory for some temporary files during
compilation. The temporary directories are not automatically
deleted after compilation. This slows down compilation
on Windows.
Switch to use GetTemporaryPath which only creates temporay
files which will be deleted automatically.
Keep the original input file name convention for Darwin host
toolchain since it is needed for deterministic binary
(https://reviews.llvm.org/D111269)
Fixes: SWDEV-386058
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D145509
Refer from: https://reviews.llvm.org/D44782
After https://reviews.llvm.org/D130302, LW+SEXT.B can be folded into LB
as partially reload stack slot. This gains incorrect optimization result
from `StackSlotColoring` without given the number of bytes exactly load
from stack. LB+SW are mis-interpreted as fully reload/restore from stack
slot without the sign-extension. SW would be considered as a redundant store.
The testcase is copied from llvm/test/CodeGen/X86/pr30821.mir.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D145471
Interleave and deinterleave shuffles are lowered by a more efficient
sequence if the element size is smaller than ELEN.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D145678
The `UBSAN`/`ASAN` plugins would previously call the internal helper
structure injected into the source expression `struct data { ... };`
This occasionally collided with user-defined types of the same (quite
common) name. In the presence of varibale with the same name LLDB would
simply fail to run the injected `InstrumentationRuntime` expressions
with:
```
warning: cannot evaluate AddressSanitizer expression:
expression failed to parse:
error: <user expression 2>:2:5: must use 'struct' tag to refer to type 'data' in this scope
data t;
```
In the presence of another type called 'data', LLDB would most likely
crash with something like:
```
0x00000001198de614 clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext*, bool) + 1088
0x00000001198de614 clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext*, bool) + 1088
0x0000000119907930 clang::ASTImporter::ImportDefinition(clang::Decl*) + 596
0x00000001163db928 lldb_private::ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(clang::Decl*, clang::Decl*) + 100
0x00000001163da070 (anonymous namespace)::CompleteTagDeclsScope::~CompleteTagDeclsScope() + 572
...
```
...because it got the types confused.
This patch makes these structures anonymous so there's no
chance of clashing with other types in the program. This is
already the approach taken in `UBSan/InstrumentationRuntimeABSan.cpp`.
**Testing**
- API tests still pass
- Tested manually that the `memory history` command now works in the presence of a local called `data`
Differential Revision: https://reviews.llvm.org/D145569
RISCV has "vfabs.v" and "vfsqrt.v" so math functions abs and sqrt
can be SLP vectorized. But others exp/log/sin/asin/sinh/asinh/...
can not.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D145562
When ObjectFileMachO::LoadCoreFileImages load a binary into the
target with a valid load address, we don't need to re-load its
segments into the Target's SectionLoadList again. But we should
still call ModulesDidLoad on these modules so breakpoints can be
inserted etc.
Fix https://github.com/llvm/llvm-project/issues/56532
Effectively, this reverts behavior introduced in https://reviews.llvm.org/D117087,
which did two things:
1. Change delayed to early conversion of return object.
2. Introduced RVO possibilities because of early conversion.
This patches fixes (1) and removes (2). I already worked on a follow up for (2)
in a separated patch. I believe it's important to split these two because if the RVO
causes any problems we can explore reverting (2) while maintaining (1).
Notes on some testcase changes:
- `pr59221.cpp` changed to `-O1` so we can check that the front-end honors
the value checked for. Sounds like `-O3` without RVO is more likely
to work with LLVM optimizations...
- Comment out delete members `coroutine-no-move-ctor.cpp` since behavior
now requires copies again.
Differential Revision: https://reviews.llvm.org/D145639
On Android, the _COARSE version of clock_gettime is about twice as fast.
Therefore, add a getMonotonicTimeFast function that is used in the
releaseToOSMaybe functions.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D145636
Testing the COFFPlatform on MSVC, a name shadowing issue surfaced where `LoadDynLibrary` inside the constructor was actually using the moved-from function argument. This patch simply renames the argument to avoid that shadowing.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D145710
