llvm-project.git/llvm/lib/Bitcode/Reader/BitcodeReader.cpp, branch users/vitalybuka/spr/main.analysis-exclude-llvmallowruntimeubsancheck-from-aliassettracker

[IR] Add nowrap flags for trunc instruction (#85592)

2024-03-29T06:08:49+00:00

This patch adds the nuw (no unsigned wrap) and nsw (no signed wrap)
poison-generating flags to the trunc instruction.

Discourse thread:
https://discourse.llvm.org/t/rfc-add-nowrap-flags-to-trunc/77453

NFC Rename LoadBitcodeIntoNewDbgInforFormat to LoadBitcodeIntoNewDbgInfoFormat

2024-03-22T12:22:00+00:00

(drop additional 'r' before Format)

[RemoveDIs][NFC] Rename DPLabel->DbgLabelRecord (#85918)

2024-03-20T13:11:28+00:00

This patch renames DPLabel to DbgLabelRecord, in accordance with the
ongoing DbgRecord rename. This rename was fairly trivial, since DPLabel
isn't as widely used as DPValue and has no real conflicts in either its
full or abbreviated name. As usual, the entire replacement was done
automatically, with `s/DPLabel/DbgLabelRecord/` and `s/DPL/DLR/`.

[IR] Change representation of getelementptr inrange (#84341)

2024-03-20T09:59:45+00:00

As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the representation of the `inrange` attribute, which
is used for vtable splitting.

Currently, inrange is specified as follows:

```
getelementptr inbounds ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, inrange i32 1, i64 2)
```

The `inrange` is placed on a GEP index, and all accesses must be "in
range" of that index. The new representation is as follows:

```
getelementptr inbounds inrange(-16, 16) ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, i32 1, i64 2)
```

This specifies which offsets are "in range" of the GEP result. The new
representation will continue working when canonicalizing to ptradd
representation:

```
getelementptr inbounds inrange(-16, 16) (i8, ptr @vt, i64 48)
```

The inrange offsets are relative to the return value of the GEP. An
alternative design could make them relative to the source pointer
instead. The result-relative format was chosen on the off-chance that we
want to extend support to non-constant GEPs in the future, in which case
this variant is more expressive.

This implementation "upgrades" the old inrange representation in bitcode
by simply dropping it. This is a very niche feature, and I don't think
trying to upgrade it is worthwhile. Let me know if you disagree.

[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)

2024-03-19T20:07:07+00:00

This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:

- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.

Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:

```
  DPValue -> DbgVariableRecord
  DPVal -> DbgVarRec
  DPV -> DVR
```

Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.

[RemoveDIs] Add flag to control loading into new debug mode from bitcode (#85649)

2024-03-19T12:12:35+00:00

--load-bitcode-into-experimental-debuginfo-iterators

      false: Convert to the old debug mode after reading.
      true: Upgrade to the new debug info format (*).
      unset: Same as false (for now).

(*) As of this patch it actually just means "don't convert to either
mode after loading". Auto-upgrading will be implemented in an upcoming
patch.

With this flag we can incrementally add support for RemoveDIs by
overriding the "unset" behaviour in individual tools. The flag can be
removed once all tools support the new debug info mode.

Reapply [RemoveDIs] Read/write DbgRecords directly from/to bitcode (#83251)

2024-03-15T12:33:55+00:00

Reaplying after revert in #85382 (861ebe6446296c96578807363aa292c69d827773).
Fixed intermittent test failure by avoiding piping output in some RUN lines.

If --write-experimental-debuginfo-iterators-to-bitcode is true (default false)
and --expermental-debuginfo-iterators is also true then the new debug info
format (non-instruction records) is written to bitcode directly.

Added the following records:

    FUNC_CODE_DEBUG_RECORD_LABEL
    FUNC_CODE_DEBUG_RECORD_VALUE
    FUNC_CODE_DEBUG_RECORD_DECLARE
    FUNC_CODE_DEBUG_RECORD_ASSIGN
    FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE

The last one has an abbrev in FUNCTION_BLOCK BLOCK_INFO. Incidentally, this uses
the last value available without widening the code-length for FUNCTION_BLOCK
from 4 to 5 bits.

Records are formatted as follows:

    All DbgRecord start with:
      1. DILocation

      FUNC_CODE_DEBUG_RECORD_LABEL
        2. DILabel

      DPValues then share common fields:
        2. DILocalVariable
        3. DIExpression

        FUNC_CODE_DEBUG_RECORD_VALUE
          4. Location Metadata

        FUNC_CODE_DEBUG_RECORD_DECLARE
          4. Location Metadata

        FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE
	  4. Location Value (single)

        FUNC_CODE_DEBUG_RECORD_ASSIGN
	  4. Location Metadata
	  5. DIAssignID
	  6. DIExpression (address)
	  7. Location Metadata (address)

Encoding the DILocation metadata reference directly appeared to yield smaller
bitcode files than encoding the operands seperately (as is done with instruction
DILocations).

FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE is by far the most common DbgRecord record
in optimized code (order of 5x-10x over other kinds). Unoptimized code should
only contain FUNC_CODE_DEBUG_RECORD_DECLARE.

Revert "[RemoveDIs] Read/write DbgRecords directly from/to bitcode" (#85382)

2024-03-15T11:04:21+00:00

Reverts llvm/llvm-project#83251

Buildbot: https://lab.llvm.org/buildbot/#/builders/139/builds/61485

[RemoveDIs] Read/write DbgRecords directly from/to bitcode (#83251)

2024-03-15T10:47:48+00:00

If --write-experimental-debuginfo-iterators-to-bitcode is true (default false)
and --expermental-debuginfo-iterators is also true then the new debug info
format (non-instruction records) is written to bitcode directly.

Added the following records:

    FUNC_CODE_DEBUG_RECORD_LABEL
    FUNC_CODE_DEBUG_RECORD_VALUE
    FUNC_CODE_DEBUG_RECORD_DECLARE
    FUNC_CODE_DEBUG_RECORD_ASSIGN
    FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE

The last one has an abbrev in FUNCTION_BLOCK BLOCK_INFO. Incidentally, this uses
the last value available without widening the code-length for FUNCTION_BLOCK
from 4 to 5 bits.

Records are formatted as follows:

    All DbgRecord start with:
      1. DILocation

      FUNC_CODE_DEBUG_RECORD_LABEL
        2. DILabel

      DPValues then share common fields:
        2. DILocalVariable
        3. DIExpression

        FUNC_CODE_DEBUG_RECORD_VALUE
          4. Location Metadata

        FUNC_CODE_DEBUG_RECORD_DECLARE
          4. Location Metadata

        FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE
	  4. Location Value (single)

        FUNC_CODE_DEBUG_RECORD_ASSIGN
	  4. Location Metadata
	  5. DIAssignID
	  6. DIExpression (address)
	  7. Location Metadata (address)

Encoding the DILocation metadata reference directly appeared to yield smaller
bitcode files than encoding the operands seperately (as is done with instruction
DILocations).

FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE is by far the most common DbgRecord record
in optimized code (order of 5x-10x over other kinds). Unoptimized code should
only contain FUNC_CODE_DEBUG_RECORD_DECLARE.

Reapply [IR] Add new Range attribute using new ConstantRange Attribute type (#84617)

2024-03-09T11:47:43+00:00

The only change from https://github.com/llvm/llvm-project/pull/83171 is the
change of the allocator so the destructor is called for
ConstantRangeAttributeImpl.

reverts https://github.com/llvm/llvm-project/pull/84549