[llvm] Use SmallString::str (NFC) (#92712)

[lld] Fix -ObjC load behavior with LTO (#92162)

When -ObjC is passed, the linker must force load any object files that
contain special sections that store Objective-C / Swift information that
is u

[lld] Fix -ObjC load behavior with LTO (#92162)

When -ObjC is passed, the linker must force load any object files that
contain special sections that store Objective-C / Swift information that
is used at runtime.

This should work regadless if input files are bitcode or native, but it
was not working with bitcode. This is because the sections that identify
an object file that should be loaded were inconsistent when dealing with
a native file vs bitcode file. In particular, bitcode files were not
searched for `__TEXT,__swift` prefixed sections, while native files
were.

This means LLD wasn't loading certain bitcode files and forcing the user
to introduce --force-load to their linker invocation for that archive.

Co-authored-by: Nuri Amari <nuriamari@fb.com>

show more ...

Revert "Repply#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)""

This reverts commit 91446e2aa687ec57ad88dc0df793d0c6e694a7c9 and
a unittest followup 1530f319311908b06fe93

Revert "Repply#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)""

This reverts commit 91446e2aa687ec57ad88dc0df793d0c6e694a7c9 and
a unittest followup 1530f319311908b06fe935c89fca692d3e53184f (#90476).

In a stage-2 -flto=thin -gsplit-dwarf -g -fdebug-info-for-profiling
-fprofile-sample-use= build of clang, a ThinLTO backend compile has
assertion failures:

Global is external, but doesn't have external or weak linkage!
ptr @_ZN5clang12ast_matchers8internal18makeAllOfCompositeINS_8QualTypeEEENS1_15BindableMatcherIT_EEN4llvm8ArrayRefIPKNS1_7MatcherIS5_EEEE
function declaration may only have a unique !dbg attachment
ptr @_ZN5clang12ast_matchers8internal18makeAllOfCompositeINS_8QualTypeEEENS1_15BindableMatcherIT_EEN4llvm8ArrayRefIPKNS1_7MatcherIS5_EEEE

The failures somehow go away if -fprofile-sample-use= is removed.

show more ...

[llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (#91441)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber Stri

[llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (#91441)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::equals by a factor of
70 under llvm/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".

show more ...

Revert "Reapply "Use an abbrev to reduce size of VALUE_GUID records in ThinLTO summaries" (#90610)" (#91194)

Reverts llvm/llvm-project#90692

Breaking PPC buildbots. The bots are not meant to test

Revert "Reapply "Use an abbrev to reduce size of VALUE_GUID records in ThinLTO summaries" (#90610)" (#91194)

Reverts llvm/llvm-project#90692

Breaking PPC buildbots. The bots are not meant to test LLD, but are
running a test that is using an old version of LLD without the change
(so is incompatible). Revert until a fix is found.

show more ...

Repply#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reapplies the original commit:
2f01fd99eb8c8ab3db9aba72c4f00e31e9e60a05

The previous application of this patch f

Repply#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reapplies the original commit:
2f01fd99eb8c8ab3db9aba72c4f00e31e9e60a05

The previous application of this patch failed due to some missing
DbgVariableRecord support in clang, which has been added now by commit
8805465e.

This will probably break some downstream tools that don't already handle
debug records. If your downstream code breaks as a result of this
change, the simplest fix is to convert the module in question to the old
debug format before you process it, using
`Module::convertFromNewDbgValues()`. For more information about how to
handle debug records or about what has changed, see the migration
document:
https://llvm.org/docs/RemoveDIsDebugInfo.html

This reverts commit 4fd319ae273ed6c252f2067909c1abd9f6d97efa.

show more ...

Revert#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reverted following probably-causing failures on some clang buildbots:
https://lab.llvm.org/buildbot/#/builders/24

Revert#2 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Reverted following probably-causing failures on some clang buildbots:
https://lab.llvm.org/buildbot/#/builders/245/builds/24037

This reverts commit a12622543de15df45fb9ad64e8ab723289d55169.

show more ...

Reapply "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Fixes the broken tests in the original commit:
2f01fd99eb8c8ab3db9aba72c4f00e31e9e60a05

This will probably break

Reapply "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Fixes the broken tests in the original commit:
2f01fd99eb8c8ab3db9aba72c4f00e31e9e60a05

This will probably break some downstream tools that don't already handle
debug records. If your downstream code breaks as a result of this
change, the simplest fix is to convert the module in question to the old
debug format before you process it, using
`Module::convertFromNewDbgValues()`. For more information about how to
handle debug records or about what has changed, see the migration
document:
https://llvm.org/docs/RemoveDIsDebugInfo.html

This reverts commit 00821fed09969305b0003d3313c44d1e761a7131.

show more ...

Reapply "Use an abbrev to reduce size of VALUE_GUID records in ThinLTO summaries" (#90610) (#90692)

This reverts commit 2aabfc811670beb843074c765c056fff4a7b443b.

Add fixes to LLD and Gold tests m

Reapply "Use an abbrev to reduce size of VALUE_GUID records in ThinLTO summaries" (#90610) (#90692)

This reverts commit 2aabfc811670beb843074c765c056fff4a7b443b.

Add fixes to LLD and Gold tests missed in original change.

Co-authored-by: Jan Voung <jvoung@google.com>

show more ...

Revert "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

A unit test was broken by the above commit:
https://lab.llvm.org/buildbot/#/builders/139/builds/64627

This reverts

Revert "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

A unit test was broken by the above commit:
https://lab.llvm.org/buildbot/#/builders/139/builds/64627

This reverts commit 2f01fd99eb8c8ab3db9aba72c4f00e31e9e60a05.

show more ...

[RemoveDIs] Load into new debug info format by default in LLVM (#89799)

This patch enables parsing and creating modules directly into the new
debug info format. Prior to this patch, all modules wer

[RemoveDIs] Load into new debug info format by default in LLVM (#89799)

This patch enables parsing and creating modules directly into the new
debug info format. Prior to this patch, all modules were constructed
with the old debug info format by default, and would be converted into
the new format just before running LLVM passes. This is an important
milestone, in that this means that every tool will now be exposed to
debug records, rather than those that run LLVM passes. As far as I've
tested, all LLVM tools/projects now either handle debug records, or
convert them to the old intrinsic format.

There are a few unit tests that need updating for this patch; these are
either cases of tests that previously needed to set the debug info
format to function, or tests that depend on the old debug info format in
some way. There should be no visible change in the output of any LLVM
tool as a result of this patch, although the likelihood of this patch
breaking downstream code means an NFC tag might be a little misleading,
if not technically incorrect:

This will probably break some downstream tools that don't already handle
debug records. If your downstream code breaks as a result of this
change, the simplest fix is to convert the module in question to the old
debug format before you process it, using
`Module::convertFromNewDbgValues()`. For more information about how to
handle debug records or about what has changed, see the migration
document:
https://llvm.org/docs/RemoveDIsDebugInfo.html

show more ...

Revert "Use an abbrev to reduce size of VALUE_GUID records in ThinLTO summaries" (#90610)

Reverts llvm/llvm-project#90497
Broke some LLD tests.

Use an abbrev to reduce size of VALUE_GUID records in ThinLTO summaries (#90497)

GUID often have content in the higher bits of a 64-bit entry so using
the unabbrev encoding is inefficient (lots of

Use an abbrev to reduce size of VALUE_GUID records in ThinLTO summaries (#90497)

GUID often have content in the higher bits of a 64-bit entry so using
the unabbrev encoding is inefficient (lots of VBR control bits).
Instead, use an abbrev with two 32-bit fixed width chunks.
The abbrev also helps encode the "count" in one place instead of
in every record.

Reduces size of distributed backend summary files by 8.7% in one
example app.

Co-authored-by: Jan Voung <jvoung@google.com>

show more ...

[DebugInfo][RemoveDIs] Fix error from not tracking seen debug labels (#88718)

Fixes the reported errors on:
https://github.com/llvm/llvm-project/pull/87379

A previous patch updated the bitcode r

[DebugInfo][RemoveDIs] Fix error from not tracking seen debug labels (#88718)

Fixes the reported errors on:
https://github.com/llvm/llvm-project/pull/87379

A previous patch updated the bitcode reading for debug
intrinsics/records to not perform the expensive debug info format
conversion from records to intrinsics in cases where no records were
present, but the patch did not actually track when debug labels had been
seen, resulting in errors when parsing bitcode where functions contained
debug label records but no other debug records. This patch fixes that
case and adds a test for it.

show more ...

[ThinLTO]Record import type in GlobalValueSummary::GVFlags (#87597)

The motivating use case is to support import the function declaration
across modules to construct call graph edges for indirect c

[ThinLTO]Record import type in GlobalValueSummary::GVFlags (#87597)

The motivating use case is to support import the function declaration
across modules to construct call graph edges for indirect calls [1]
when importing the function definition costs too much compile time
(e.g., the function is too large has no `noinline` attribute).
1. Currently, when the compiled IR module doesn't have a function
definition but its postlink combined summary contains the function
summary or a global alias summary with this function as aliasee, the
function definition will be imported from source module by IRMover. The
implementation is in FunctionImporter::importFunctions [2]
2. In order for FunctionImporter to import a declaration of a function,
both function summary and alias summary need to carry the def / decl
state. Specifically, all existing summary fields doesn't differ across
import modules, but the def / decl state of is decided by
`<ImportModule, Function>`.

This change encodes the def/decl state in `GlobalValueSummary::GVFlags`.

In the subsequent changes
1. The indexing step `computeImportForModule` [3]
will compute the set of definitions and the set of declarations for each
module, and passing on the information to bitcode writer.
2. Bitcode writer will look up the def/decl state and sets the state
when it writes out the flag value. This is demonstrated in
https://github.com/llvm/llvm-project/pull/87600
3. Function importer will read the def/decl state when reading the
combined summary to figure out two sets of global values, and IRMover
will be updated to import the declaration (aka linkGlobalValuePrototype [4])
into the destination module.

- The next change is https://github.com/llvm/llvm-project/pull/87600

[1] mentioned in rfc https://discourse.llvm.org/t/rfc-for-better-call-graph-sort-build-a-more-complete-call-graph-by-adding-more-indirect-call-edges/74029#support-cross-module-function-declaration-import-5
[2] https://github.com/llvm/llvm-project/blob/3b337242ee165554f0017b00671381ec5b1ba855/llvm/lib/Transforms/IPO/FunctionImport.cpp#L1608-L1764
[3] https://github.com/llvm/llvm-project/blob/3b337242ee165554f0017b00671381ec5b1ba855/llvm/lib/Transforms/IPO/FunctionImport.cpp#L856
[4] https://github.com/llvm/llvm-project/blob/3b337242ee165554f0017b00671381ec5b1ba855/llvm/lib/Linker/IRMover.cpp#L605

show more ...

Add support for `nneg` flag with `uitofp`

As noted when #82404 was pushed (canonicalizing `sitofp` -> `uitofp`),
different signedness on fp casts can have dramatic performance
implications on differ

Add support for `nneg` flag with `uitofp`

As noted when #82404 was pushed (canonicalizing `sitofp` -> `uitofp`),
different signedness on fp casts can have dramatic performance
implications on different backends.

So, it makes to create a reliable means for the backend to pick its
cast signedness if either are correct.

Further, this allows us to start canonicalizing `sitofp`- > `uitofp`
which may easy middle end analysis.

Closes #86141

show more ...

[RemoveDIs] Add flag to preserve the debug info format of input IR (#87379)

This patch adds a new flag: `--preserve-input-debuginfo-format`

This flag instructs the tool to not convert the debug i

[RemoveDIs] Add flag to preserve the debug info format of input IR (#87379)

This patch adds a new flag: `--preserve-input-debuginfo-format`

This flag instructs the tool to not convert the debug info format
(intrinsics/records) of input IR, but to instead determine the format of
the input IR and overwrite the other format-determining flags so that we
process and output the file in the same format that we received it in.
This flag is turned off by llvm-link, llvm-lto, and llvm-lto2, and
should be turned off by any other tool that expects to parse multiple IR
modules and have their debug info formats match.

The motivation for this flag is to allow tools to not convert the debug
info format - verify-uselistorder and llvm-reduce, and any downstream
tools that seek to test or mutate IR as-is, without applying extraneous
modifications to the input. This is a necessary step to using debug
records by default in all (other) LLVM tools.

show more ...

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

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

Discourse thread:
htt

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

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

show more ...

NFC Rename LoadBitcodeIntoNewDbgInforFormat to LoadBitcodeIntoNewDbgInfoFormat

(drop additional 'r' before Format)

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

This patch renames DPLabel to DbgLabelRecord, in accordance with the
ongoing DbgRecord rename. This rename was fairly trivial, since DPLabel

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

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/`.

show more ...

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

As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the

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

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.

show more ...

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

This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which re

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

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.

show more ...

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

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

false: Convert to the old debug mode after reading.

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

--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.

show more ...

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

Reaplying after revert in #85382 (861ebe6446296c96578807363aa292c69d827773).
Fixed intermittent test failure by avoiding p

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

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.

show more ...

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

Reverts llvm/llvm-project#83251

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