This change introduces a version 3 of the PSV data that includes support
for the name of the entry function as an offset into StringTable data to
a null-terminated utf-8 string.
Additional tests were added to ensure that the new value was properly
serialized/deserialized from object data.
Fixes#80175
---------
Co-authored-by: Cooper Partin <coopp@ntdev.microsoft.com>
Relax assumptions that YAML output is not supported in BAT mode.
Set up basic infrastructure for emitting YAML for functions not covered
by BAT, such as from `.bolt.org.text` section (code identical to input binary
sans external refs), or non-rewritten functions in non-relocation mode (where
the function stays in the same section but BAT mapping is not emitted).
This diff only produces YAML profile for non-BAT functions (skipped,
non-simple). YAML profile for BAT functions is added in follow-up diffs:
- https://github.com/llvm/llvm-project/pull/76911 emits YAML profile with
internal control flow information only (branch profile),
- https://github.com/llvm/llvm-project/pull/76896 adds cross-function profile
(calls profile).
Test Plan: Added bolt/test/X86/bolt-address-translation-yaml.test
Reviewers: ayermolo, dcci, maksfb, rafaelauler
Reviewed By: rafaelauler
Pull Request: https://github.com/llvm/llvm-project/pull/76910
Runtime code modification used by static keys is the most ubiquitous
self-modifying feature of the Linux kernel. The idea is to to eliminate
the condition check and associated conditional jump on a hot path if
that condition (based on a boolean value of a static key) does not
change often. Whenever they condition changes, the kernel runtime
modifies all code paths associated with that key flipping the code
between nop and (unconditional) jump.
Finally getting back to Debuginfod tests:
I've migrated the tests in my [earlier
PR](https://github.com/llvm/llvm-project/pull/79181) from shell to API
(at @JDevlieghere's suggestion) and addressed a couple issues that came
about during testing.
The tests first test the "normal" situation (no DebugInfoD involvement,
just normal debug files sitting around), then the "no debug info"
situation (to make sure the test is seeing failure properly), then it
tests to validate that when Debuginfod returns the symbols, things work
properly. This is duplicated for DWP/split-dwarf scenarios.
---------
Co-authored-by: Kevin Frei <freik@meta.com>
Folding a select-like `shufflevector` into a floating point binary
operators can only be done if the result is preserved for both case. In
particular, if the common operand of the `shufflevector` and the
floating point binary operator can be a NaN, then the transformation
won't preserve the result value.
We want to add -Wcast-function-type to -Wextra (as done in
1de7e6c8cba27296f3fc16d107822ea0ee856759), but we do not want to add
-Wcast-function-type-strict in at the same time
(https://lab.llvm.org/buildbot/#/builders/57/builds/33601/steps/5/logs/stdio).
This moves the existing warning to a new group
(-Wcast-function-type-mismatch), puts the new group under the existing
-Wcast-function-type warning group, and adds
-Wcast-function-type-mismatch to -Wextra.
With one raw memprof file I have, NumPCs averages about 41. Given the
default number of inline elements being 8 for SmallVector<uint64_t>,
we should reserve the storage in advance.
The MinBW was being calculated using the significant bits of the upper
and lower bounds. The upper bound is 1 past the last value in the range
so I don't think it should be included. Instead use ConstantRange::getMinSignedBits.
I'm still not sure if the +1 is needed after the getMinSignedBits call.
This PR fixes a subset of procedure pointer component initialization in
structure constructor.
It covers
1. NULL()
2. procedure
For example:
```
MODULE M
TYPE :: DT
!PROCEDURE(Fun), POINTER, NOPASS :: pp1
PROCEDURE(Fun), POINTER :: pp1
END TYPE
CONTAINS
INTEGER FUNCTION Fun(Arg)
class(dt) :: arg
END FUNCTION
END MODULE
PROGRAM MAIN
USE M
IMPLICIT NONE
TYPE (DT), PARAMETER :: v1 = DT(NULL())
TYPE (DT) :: v2
v2 = DT(fun)
END
```
Passing a procedure pointer itself or reference to a function that
returns a procedure pointer is TODO.
Fixes https://github.com/llvm/llvm-project/issues/84463
Changes:
- Adapted MemRegion::getDescriptiveName
- Added unittest to check name for a given clang::ento::ElementRegion
- Some format changes due to clang-format
---------
Co-authored-by: Andreas Steinhausen <andreas.steinhausen@concenrio.io>
Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
Inside the ExprEngine when we process the initializers, we create a
PostInitializer program-point, which will refer to the field being
initialized, see `FieldLoc` inside `ExprEngine::ProcessInitializer`.
When a constructor (of which we evaluate the initializer-list) is
analyzed in top-level context, then the `this` pointer will be
represented by a `SymbolicRegion`, (as it should be).
This means that we will form a `FieldRegion{SymbolicRegion{.}}` as the
initialized region.
```c++
class Bear {
public:
void brum() const;
};
class Door {
public:
// PostInitializer would refer to "FieldRegion{SymRegion{this}}"
// whereas in the store and everywhere else it would be:
// "FieldRegion{ELementRegion{SymRegion{Ty*, this}, 0, Ty}".
Door() : ptr(nullptr) {
ptr->brum(); // Bug
}
private:
Bear* ptr;
};
```
We (as CSA folks) decided to avoid the creation of FieldRegions directly
of symbolic regions in the past:
f8643a9b31
---
In this patch, I propose to also canonicalize it as in the mentioned
patch, into this: `FieldRegion{ElementRegion{SymbolicRegion{Ty*, .}, 0,
Ty}`
This would mean that FieldRegions will/should never simply wrap a
SymbolicRegion directly, but rather an ElementRegion that is sitting in
between.
This patch should have practically no observable effects, as the store
(due to the mentioned patch) was made resilient to this issue, but we
use `PostInitializer::getLocationValue()` for an alternative reporting,
where we faced this issue.
Note that in really rare cases it suppresses now dereference bugs, as
demonstrated in the test. It is because in the past we failed to follow
the region of the PostInitializer inside the StoreSiteFinder visitor -
because it was using this code:
```c++
// If this is a post initializer expression, initializing the region, we
// should track the initializer expression.
if (std::optional<PostInitializer> PIP =
Pred->getLocationAs<PostInitializer>()) {
const MemRegion *FieldReg = (const MemRegion *)PIP->getLocationValue();
if (FieldReg == R) {
StoreSite = Pred;
InitE = PIP->getInitializer()->getInit();
}
}
```
Notice that the equality check didn't pass for the regions I'm
canonicalizing in this patch.
Given the nature of this change, we would rather upstream this patch.
CPP-4954
Fixes#75975.
Remove `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` for the LLVM 19
release, it was previously marked as deprecated in LLVM 18.
I believe that
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` was only
used by Google in conjunction with
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`.
Removing both macros together should not cause any issues in practice,
even though we did not announce the removal of
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` before.
SYS_rename may be unavailable on architectures such as aarch64 and
riscv.
rename can be implemented in terms of SYS_rename, SYS_renameat, or
SYS_renameat2. I don't have a full picture of the history here, but it
seems
that SYS_renameat might also be unavailable on some platforms.
`man 2 rename` mentions that SYS_renameat2 was added in Linux 3.15. We
don't
need to support such ancient kernel versions prior.
Link: #84980
Link: #85068
We were passing the min and max values of the range to the ConstantRange
constructor, but the constructor expects the upper bound to 1 more than
the max value so we need to add 1.
We also need to use getNonEmpty so that passing 0, 0 to the constructor
creates a full range rather than an empty range. And passing smin,
smax+1 doesn't cause an assertion.
I believe this fixes at least some of the reason #79158 was reverted.
Previously we used BuildPairF64 and SplitF64 only if Zfa was supported
since they will select register file moves that are only available with
Zfa.
We recently changed the handling of BuildPairF64/SplitF64 for Zdinx to
not go through memory so we should use that for bitcast.
That leaves the D without Zfa case that does need to go through memory.
Previously we let type legalization expand to loads and stores using a
new stack temporary created for each bitcast. After this patch we will
create the loads ands stores in the custom inserter and share the same
stack slot for all. This also allows DAGCombiner to optimize when
bitcast is mixed with BuildPairF64/SplitF64.
The Doxygen comments for the `details` field of a progress report
currently does not specify that this field will act as the initial set
of details for a progress report that gets updated with
`Progress::Increment()`. This commit clarifies this.
Investigate the lowering of MemRef Load/Store ops and implement
additional folding of created ops
Aims to improve readability of generated lowered SPIR-V code.
Part of work llvm#70704
The range for these operations is being constructed without the
maximum value for the range due to an incorrect usage of the
ConstantRange constructor.
This causes Float2Int to think the range for 'uitofp i1' only
contains 0 instead of 0 and 1.
This is another step towards supporting DWARF5 checksums and inline
source code in LLDB. This is a reland of #85468 but without the
functional change of storing the support file from the line table (yet).
Dwarf 5 allows separating filenames from .debug_line into a separate
.debug_line_str section. The strings are referenced relative to the
start of the .debug_line_str section. Previously, on COFF, the
relocation information instead caused offsets to be relocated to the
base address of the COFF-File. This lead to wrong offsets in linked
COFF (PE) files which caused the debugger to be unable to find the
correct source files.
This patch fixes this problem by making the offsets relative to the
start of the .debug_line_str section instead. There should be no
changes for ELF-Files as everything seems to be working there.
A test is also added to ensure that the correct relocation entries are
emitted.
This reapplies 272d1b44efdedb68c194970a610f0ca1b7b769c5 (from #85756),
which was reverted in
407937036fa7640f61f225474b1ea6623a40dbdd.
In the previous attempt, empty CMAKE_INSTALL_PREFIX was handled by
quoting them, in d209d1340b99d4fbd325dffb5e13b757ab8264ea. That made the
calls to cmake_path(ABSOLUTE_PATH) succeed, but the output paths of that
weren't actually absolute, which was required by file(RELATIVE_PATH).
Avoid this issue by constructing a non-empty base directory variable
to use for calculating the relative path.
I believe we can use XLen alignment as long as eliminateFrameIndex
limits the maximum folded offset to 2043. This way when we split
the load/store into two 2 instructions we'll be able to add 4
without overflowing simm12.
Allow targets to rely on TargetLowering::isGuaranteedNotToBeUndefOrPoisonForTargetNode to test nodes for canCreateUndefOrPoisonForTargetNode + all arguments are isGuaranteedNotToBeUndefOrPoison.
Targets can still perform this themselves for specific special case nodes (e.g. target shuffles).
Matches the fallback in SelectionDAG::isGuaranteedNotToBeUndefOrPoison
NFC.
gfx11_asm_vinterp.s already contained GFX12 run lines. Rename the
assembler and disassembler tests to be sorted based on real16 or fake16
instead of gfxip. Note, both GFX11 and GFX12 currently only have fake16
(fake16 in encoding, but not by name) upstream, so that is why the test
files have a -fake16 suffix.
One test input is changed, and that is the disassembler test for
unsupported bits in the instruction. It is now an input that is valid on
both GFX11 and GFX12. This was necessary because the size of the opcode
field changed.
