Allow empty range attribute and add assert for full range (#100601)

fix #99619

[LLParser] Use SmallVector instead of std::vector (#100916)

The use of SmallVector here saves 1.03% of heap allocations during the
compilation of X86ISelLowering.cpp.ll, a .ll version of
X86ISelLo

[LLParser] Use SmallVector instead of std::vector (#100916)

The use of SmallVector here saves 1.03% of heap allocations during the
compilation of X86ISelLowering.cpp.ll, a .ll version of
X86ISelLowering.cpp. The 8 inline elements cover greater than 99% of
invocations encountered here.

While I am it, the patch changes the parameter type to ArrayRef to
allow callers to use any vector type.

show more ...

[MIR] Replace bespoke DIExpression parser

Resolve FIXME by using the LLParser implementation of parseDIExpression
from the MIParser.

[AsmParser] Use range-based for loops (NFC) (#97499)

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, re

[IR] Add getDataLayout() helpers to Function and GlobalValue (#96919)

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.

show more ...

[LLParser] Use poison instead of undef when cleaning up forward refs

Add the 'initializes' attribute langref and support (#84803)

We propose adding a new LLVM attribute,
`initializes((Lo1,Hi1),(Lo2,Hi2),...)`, which expresses the notion of
memory space (i.e., inter

Add the 'initializes' attribute langref and support (#84803)

We propose adding a new LLVM attribute,
`initializes((Lo1,Hi1),(Lo2,Hi2),...)`, which expresses the notion of
memory space (i.e., intervals, in bytes) that the argument pointing to
is initialized in the function.

Will commit the attribute inferring in the follow-up PRs.


https://discourse.llvm.org/t/rfc-llvm-new-initialized-parameter-attribute-for-improved-interprocedural-dse/77337

show more ...

Revert "[DebugInfo][BPF] Add 'annotations' field for DIBasicType & DI… (#96172)

…SubroutineType (#91422)"

This reverts commit 3ca17443ef4af21bdb1f3b4fbcfff672cbc6176c.

As reported in [1,2] the

Revert "[DebugInfo][BPF] Add 'annotations' field for DIBasicType & DI… (#96172)

…SubroutineType (#91422)"

This reverts commit 3ca17443ef4af21bdb1f3b4fbcfff672cbc6176c.

As reported in [1,2] the commit above causes CI failure for powerpc-aix
target.
There is also a performance regression reported in [3]. Reverting to
comply with the developer policy.

[1]
https://github.com/llvm/llvm-project/pull/91422#issuecomment-2179425473
[2] https://lab.llvm.org/buildbot/#/builders/64/builds/62
[3]
https://github.com/llvm/llvm-project/pull/91422#issuecomment-2175631443

show more ...

[IR] Remove support for shl constant expressions (#96037)

Remove support for shl constant expressions, as part of:
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179

[DebugInfo][BPF] Add 'annotations' field for DIBasicType & DISubroutineType (#91422)

Extend `DIBasicType` and `DISubroutineType` with additional field
`annotations`, e.g. as below:

```
!5 = !

[DebugInfo][BPF] Add 'annotations' field for DIBasicType & DISubroutineType (#91422)

Extend `DIBasicType` and `DISubroutineType` with additional field
`annotations`, e.g. as below:

```
!5 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed, annotations: !6)
!6 = !{!7}
!7 = !{!"btf:type_tag", !"tag1"}
```

The field would be used by BPF backend to generate DWARF attributes
corresponding to `btf_type_tag` type attributes, e.g.:

```
0x00000029: DW_TAG_base_type
DW_AT_name ("int")
DW_AT_encoding (DW_ATE_signed)
DW_AT_byte_size (0x04)

0x0000002d: DW_TAG_LLVM_annotation
DW_AT_name ("btf:type_tag")
DW_AT_const_value ("tag1")
```

Such DWARF entries would be used to generate BTF definitions by tools
like [pahole](https://github.com/acmel/dwarves).

Note: similar fields with similar purposes are already present in
DIDerivedType and DICompositeType.

Currently "btf_type_tag" attributes are represented in debug information
as 'annotations' fields in DIDerivedType with DW_TAG_pointer_type tag.
The annotation on a pointer corresponds to pointee having the attributes
in the final BTF.

The discussion in
[thread](https://lore.kernel.org/bpf/87r0w9jjoq.fsf@oracle.com/) came to
conclusion, that such annotations should apply to the annotated type
itself. Hence the necessity to extend `DIBasicType` & `DISubroutineType`
types with 'annotations' field to represent cases like below:

```
int __attribute__((btf_type_tag("foo"))) bar;
```

This was previously tracked as differential revision:
https://reviews.llvm.org/D143966

show more ...

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

Reapplies commit c5aeca73 (and its followup commit 21396be8), which were
reverted due to missing functionality in

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

Reapplies commit c5aeca73 (and its followup commit 21396be8), which were
reverted due to missing functionality in MLIR and Flang regarding printing
debug records. This has now been added in commit 08aa511, along with support
for printing debug records in flang.

This reverts commit 2dc2290860355dd2bac3b655eea895fe30fde257.

show more ...

Revert new debug info format commits:

"[Flang] Update test to not check for tail calls on debug intrinsics" &
"Reapply#3 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Re

Revert new debug info format commits:

"[Flang] Update test to not check for tail calls on debug intrinsics" &
"Reapply#3 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"

Recent updates to flang have added debug info generation via MLIR, a path
which currently does not support debug records. The patch that enables
debug records by default (and a small followup patch) are thus being
reverted until the MLIR path has been fixed.

This reverts commits:
21396be865b4640abf6afa0b05de6708a1a996e0
c5aeca732d1ff6769b0659efebd1cfb5f60487e4

show more ...

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

Reapplies commit 91446e2, which was reverted due to a downstream error,
discussed on the pull request. The error c

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

Reapplies commit 91446e2, which was reverted due to a downstream error,
discussed on the pull request. The error could not be reproduced
upstream, and cannot be reproduced downstream as-of current main, so
until the error can be confirmed to still exist this patch should
return.

This reverts commit 23f8fac745bdde70ed4f9c585d19c4913734f1b8.

show more ...

[AArch64][SME] Add calling convention for __arm_get_current_vg (#93963)

Adds a calling convention for calls to the `__arm_get_current_vg`
support
routine, which preserves X1-X15, X19-X29, SP, Z0-Z

[AArch64][SME] Add calling convention for __arm_get_current_vg (#93963)

Adds a calling convention for calls to the `__arm_get_current_vg`
support
routine, which preserves X1-X15, X19-X29, SP, Z0-Z31 & P0-P15.

See https://github.com/ARM-software/abi-aa/pull/263

show more ...

[IR] Remove support for icmp and fcmp constant expressions (#93038)

Remove support for the icmp and fcmp constant expressions.

This is part of:
https://discourse.llvm.org/t/rfc-remove-most-const

[IR] Remove support for icmp and fcmp constant expressions (#93038)

Remove support for the icmp and fcmp constant expressions.

This is part of:
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179

As usual, many of the updated tests will no longer test what they were
originally intended to -- this is hard to preserve when constant
expressions get removed, and in many cases just impossible as the
existence of a specific kind of constant expression was the cause of the
issue in the first place.

show more ...

[IR][AArch64][PAC] Add "ptrauth(...)" Constant to represent signed pointers. (#85738)

This defines a new kind of IR Constant that represents a ptrauth signed
pointer, as used in AArch64 PAuth.

I

[IR][AArch64][PAC] Add "ptrauth(...)" Constant to represent signed pointers. (#85738)

This defines a new kind of IR Constant that represents a ptrauth signed
pointer, as used in AArch64 PAuth.

It allows representing most kinds of signed pointer constants used thus
far in the llvm ptrauth implementations, notably those used in the
Darwin and ELF ABIs being implemented for c/c++. These signed pointer
constants are then lowered to ELF/MachO relocations.

These can be simply thought of as a constant `llvm.ptrauth.sign`, with
the interesting addition of discriminator computation: the `ptrauth`
constant can also represent a combined blend, when both address and
integer discriminator operands are used. Both operands are otherwise
optional, with default values 0/null.

show more ...

[IR] Add getelementptr nusw and nuw flags (#90824)

This implements the `nusw` and `nuw` flags for `getelementptr` as
proposed at
https://discourse.llvm.org/t/rfc-add-nusw-and-nuw-flags-for-getelem

[IR] Add getelementptr nusw and nuw flags (#90824)

This implements the `nusw` and `nuw` flags for `getelementptr` as
proposed at
https://discourse.llvm.org/t/rfc-add-nusw-and-nuw-flags-for-getelementptr/78672.

The three possible flags are encapsulated in the new `GEPNoWrapFlags`
class. Currently this class has a ctor from bool, interpreted as the
InBounds flag. This ctor should be removed in the future, as code gets
migrated to handle all flags.

There are a few places annotated with `TODO(gep_nowrap)`, where I've had
to touch code but opted to not infer or precisely preserve the new
flags, so as to keep this as NFC as possible and make sure any changes
of that kind get test coverage when they are made.

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

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

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

[AsmParser] Support calling intrinsics without mangling suffix (#89172)

This adds proper support for calling intrinsics without mangling suffix
when parsing textual IR. This already worked (mostly

[AsmParser] Support calling intrinsics without mangling suffix (#89172)

This adds proper support for calling intrinsics without mangling suffix
when parsing textual IR. This already worked (mostly by accident) when
only a single mangling suffix was in use.

This patch extends support to the case where the intrinsic is used with
multiple signatures, and as such multiple different intrinsic
declarations have to be inserted. The final IR will have intrinsics with
mangling suffix as usual.

Motivated by the discussion at:
https://discourse.llvm.org/t/recent-improvements-to-the-ir-parser/77366

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