[Instrumentor] Add a property filter for static properties
The user can define static filters in the json to limit instrumentation
to opportunities that match the static expression, e.g., is_volatile==1.
The matcher logic is pretty basic for now. Integer comparisons, string
equalities and startswith are supported.
The commit was prepared with Claude (AI) and proofread/tested by me.
[llvm-gsymutil] Add --symtab-file option to specify separate symbol table file (#184059)
Add a `--symtab-file` option that allows specifying a separate file from
which
to read the symbol table during GSYM conversion. This is useful when
DWARF and
function symbols are stored in separate files.
Example:
`llvm-gsymutil --convert debug_info.elf --symtab-file=symbols.elf -o
output.gsym`
## Changes
- Added `--symtab-file` to `Opts.td` and command-line help.
- Parsed and used `--symtab-file` in `llvm-gsymutil.cpp` during
conversion.
- Kept architecture validation for thin object inputs.
- Added support for universal Mach-O inputs by selecting the matching
symbol-table slice for each selected
[15 lines not shown]
[lldb] Fix Broken Test For Embedded Source in Binary (#197040)
A previous change to fix a regression when displaying source of programs
that embed their source code into their debugging information (using,
e.g., DW_LNCT_LLVM_source) should display included a test that was not
appropriately robust to all platforms.
Disable the regression on Windows systems and make the CHECKs robust
against output generated on different platforms.
[IR] Account for byte width in m_PtrAdd
The method has few uses yet, so just pass DL argument to it. The change
follows m_PtrToIntSameSize, and I don't see a better way of delivering
the byte width to the method.
[IRBuilder] Add getByteTy and use it in CreatePtrAdd
The change requires DataLayout instance to be available, which, in turn,
requires insertion point to be set. In-tree tests detected only one case
when the function was called without setting an insertion point, it was
changed to create a constant expression directly.
[SimplifyLibCalls] Add initial support for non-8-bit bytes
The patch makes CharWidth argument of `getStringLength` mandatory
and ensures the correct values are passed in most cases.
This is *not* a complete support for unusual byte widths in
SimplifyLibCalls since `getConstantStringInfo` returns false for those.
The code guarded by `getConstantStringInfo` returning true is unchanged
because the changes are currently not testable.
[ValueTracking] Add CharWidth argument to getConstantStringInfo (NFC)
The method assumes that host chars and target chars have the same width.
Add a CharWidth argument so that it can bail out if the requested char
width differs from the host char width.
Alternatively, the check could be done at call sites, but this is more
error-prone.
In the future, this method will be replaced with a different one that
allows host/target chars to have different widths. The prototype will
be the same except that StringRef is replaced with something that is
byte width agnostic. Adding CharWidth argument now reduces the future
diff.
[ValueTracking] Make isBytewiseValue byte width agnostic
This is a simple change to show how easy it can be to support unusual
byte widths in the middle end.
[IR] Make @llvm.memset prototype byte width dependent
This patch changes the type of the value argument of @llvm.memset and
similar intrinsics from i8 to iN, where N is the byte width specified
in data layout string.
Note that the argument still has fixed type (not overloaded), but type
checker will complain if the type does not match the byte width.
Ideally, the type of the argument would be dependent on the address
space of the pointer argument. It is easy to do this (and I did it
downstream as a PoC), but since data layout string doesn't currently
allow different byte widths for different address spaces, I refrained
from doing it now.
[DataLayout] Add byte specification
This patch adds byte specification to data layout string.
The specification is `b:<size>`, where `<size>` is the size of a byte
in bits (later referred to as "byte width").
Limitations:
* The only values allowed for byte width are 8, 16, and 32.
16-bit bytes are popular, and my downstream target has 32-bit bytes.
These are the widths I'm going to add tests for in follow-up patches,
so this restriction only exists because other widths are untested.
* It is assumed that bytes are the same in all address spaces.
Supporting different byte widths in different address spaces would
require adding an address space argument to all DataLayout methods
that query ABI / preferred alignments because they return *byte*
alignments, and those will be different for different address spaces.
This is too much effort, but it can be done in the future if the need
arises, the specification reserves address space number before ':'.
[RISCV] Use getSignedTargetConstant for QC_MULIADD (#197032)
The coefficient is a signed value, and `getTargetConstant` is for
unsigned values. This was causing us assertion failures.
[CodeGen,IRNormalizer,BOLT] Duplicate stable hash_16_bytes locally. NFC (#196854)
llvm/ADT/Hashing.h doesn't guarantee cross-process stability.
llvm/ADT/StableHashing.h provides stability for a specific compiler
version.
They reserve the right the right to adjust the implementation as the
compiler evolves.
Some callers of hashing::detail::hash_16_bytes rely on hash output
embedded in persisted artifacts:
* MachineBlockHashInfo serializes block hashes into BB section
profile data and pins the mixer's exact output with a static_assert.
* BOLT's stale profile matching records block hashes in its on-disk
profile format and replays them against potentially-rebuilt
binaries (possibly built from a later LLVM revision).
* IRNormalizer derives basic-block names from the hash; the names
land in the normalized IR text used to diff modules.
[2 lines not shown]
[AArch64][Isel] For fixed length vectors use sve for bitreverse when available (#196025)
Lowering bitreverse via the SVE path seems to be giving significant
performance improvements for fixed width vectors
Speedups after the patch
uint8x8_t 1.01x
uint16x4_t 2.02x
uint32x2_t 2.01x
uint64x1_t 2.02x
uint8x16_t 1.00x
uint16x8_t 2.03x
uint32x4_t 2.03x
uint64x2_t 2.02x
