[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
[TableGen] Emit the primary input file in -d depfile output (#197061)
This fixes a bug where old, but still supported, versions of CMake and
ninja perpetually consider zero-include tablegen files to be out of
date. It also matches what Clang and GCC do for regular C compilations.
When a .td input has no `include` directives, the depfile produced by
`-d` contains only `<output>:` followed by zero dependencies. My version
(3.27) of CMake's `cmake_transform_depfile` step then writes a 0-byte
file, which old versions of ninja treat as a missing depfile and re-run
the rule on every incremental build (e.g. Attributes.td, ValueTypes.td).
Here's the effect on Attributes.inc.d:
```
$ cat ./build/include/llvm/IR/Attributes.inc.d
Attributes.inc:
# switch branches and rebuild...
$ cat ./build/include/llvm/IR/Attributes.inc.d
[3 lines not shown]
[Instrumentor] Allow multiple config files with different filters
To instrument different functions in different ways we allow to provide
multiple config files now. Each file will result in one instrumentation
run. Multiple files can be passed via command line option or listed in
a "summary" file that is passed via command line option (to keep the
command length managable).
[Instrumentor] Add a global function regexp to limit the instrumentation
Only functions that match the "function_regex" will be instrumented,
or if they have the instrumentation attribute.
[Instrumentor] Add unreachable support; unreachable stack trace printing
Allow to instrument unreachable and provide a use case for stack trace
printing.
