Teach the IR parser and writer to support metadata on ifuncs, and update documentation. In PR #153049, we have a use case of attaching the `!associated` metadata to an ifunc. Since an ifunc is similar to a function declaration, it seems natural to allow metadata on ifuncs. Currently, the metadata API allows adding Metadata to llvm::GlobalObject, so the in-memory IR allows for metadata on ifuncs, but the IR reader/writer is not aware of that. --------- Co-authored-by: Wael Yehia <wyehia@ca.ibm.com>
MaxAlignment is used to produce the abbreviation for MODULE_CODE_GLOBALVAR and is not used for anything related to function alignments, so stop combining function alignments and rename it to make its purpose clearer. Reviewers: teresajohnson Reviewed By: teresajohnson Pull Request: https://github.com/llvm/llvm-project/pull/155341
This introduces a new `ptrtoaddr` instruction which is similar to `ptrtoint` but has two differences: 1) Unlike `ptrtoint`, `ptrtoaddr` does not capture provenance 2) `ptrtoaddr` only extracts (and then extends/truncates) the low index-width bits of the pointer For most architectures, difference 2) does not matter since index (address) width and pointer representation width are the same, but this does make a difference for architectures that have pointers that aren't just plain integer addresses such as AMDGPU fat pointers or CHERI capabilities. This commit introduces textual and bitcode IR support as well as basic code generation, but optimization passes do not handle the new instruction yet so it may result in worse code than using ptrtoint. Follow-up changes will update capture tracking, etc. for the new instruction. RFC: https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54 Reviewed By: nikic Pull Request: https://github.com/llvm/llvm-project/pull/139357
using wrapper llvm::sort(nfc)
Serialise key-instruction fields of DILocations and DISubprograms into and outof bitcode, add tests. debug-info bitcode sizes grow, but it balances out given an earlier size optimisation in 51f4e2c. Co-authored-by: Orlando Cazalet-Hyams <orlando.hyams@sony.com>
DILocations that are not attached to instructions are encoded using METADATA_LOCATION records which have an abbrev. DILocations attached to instructions are interleaved with instruction records as FUNC_CODE_DEBUG_LOC records, which do not have an abbrev (and FUNC_CODE_DEBUG_LOC_AGAIN which have no operands). Add a new FUNCTION_BLOCK abbrev FUNCTION_DEBUG_LOC_ABBREV for FUNC_CODE_DEBUG_LOC records. This reduces the bc file size by up to 7% in CTMark, with many between 2-4% smaller. [per-file file size compile-time-tracker](https://llvm-compile-time-tracker.com/compare.php?from=75cf826849713c00829cdf657e330e24c1a2fd03&to=1e268ebd0a581016660d9d7e942495c1be041f7d&stat=size-file&details=on) (go to stage1-ReleaseLTO-g). This optimisation is motivated by #144102, which adds the new Key Instructions fields to bitcode records. The combined patches still overall look to be a slight improvement over the base. (Originally reviewed in PR #146497) Co-authored-by: Orlando Cazalet-Hyams <orlando.hyams@sony.com>
RFC on discourse:
https://discourse.llvm.org/t/rfc-debug-info-for-coroutine-suspension-locations-take-2/86606
With this commit, we add `DILabel` debug infos to the resume points of a
coroutine. Those labels can be used by debugging scripts to figure out
the exact line and column at which a coroutine was suspended by looking
up current `__coro_index` value inside the coroutines frame, and then
searching for the corresponding label inside the coroutine's resume
function.
The DWARF information generated for such a label looks like:
```
0x00000f71: DW_TAG_label
DW_AT_name ("__coro_resume_1")
DW_AT_decl_file ("generator-example.cpp")
DW_AT_decl_line (5)
DW_AT_decl_column (3)
DW_AT_artificial (true)
DW_AT_LLVM_coro_suspend_idx (0x01)
DW_AT_low_pc (0x00000000000019be)
```
The labels can be mapped to their corresponding `__coro_idx` values
either via their naming convention `__coro_resume_<N>` or using the new
`DW_AT_LLVM_coro_suspend_idx` attribute. In gdb, those line numebrs can
be looked up using `info line -function my_coroutine -label
__coro_resume_1`. LLDB unfortunately does not understand DW_TAG_label
debug information, yet.
Given this is an artificial compiler-generated label, I did apply the
DW_AT_artificial tag to it. The DWARFv5 standard only allows that tag on
type and variable definitions, but this is a natural extension and was
also blessed in the RFC on discourse.
Also, this commit adds `DW_AT_decl_column` to labels, not only for
coroutines but also for normal C and C++ labels. While not strictly
necessary, I am doing so now because it would be harder to do so later
without breaking the binary LLVM-IR format
Drive-by fixes: While reading the existing test cases to understand how
to write my own test case, I did a couple of small typo fixes and
comment improvements
Add abbreviations for icmp/fcmp, store and br, which are the most common instructions that don't have abbreviations yet. This requires increasing the abbreviation size to 5 bits. This gives about 3-5% bitcode size reductions for the clang build.
We always use the same abbreviations for type and for value references, so avoid repeating them.
Add `dead_on_return` attribute, which is meant to be taken advantage by the frontend, and states that the memory pointed to by the argument is dead upon function return. As with `byval`, it is supposed to be used for passing aggregates by value. The difference lies in the ABI: `byval` implies that the pointer is explicitly passed as argument to the callee (during codegen the copy is emitted as per byval contract), whereas a `dead_on_return`-marked argument implies that the copy already exists in the IR, is located at a specific stack offset within the caller, and this memory will not be read further by the caller upon callee return – or otherwise poison, if read before being written. RFC: https://discourse.llvm.org/t/rfc-add-dead-on-return-attribute/86871.