[AsmParser] Remove some redundant checks for align attributes

The verifier already has a more general check that the attribute is
legal for the position it is used in.

[llvm] Clear the ForwardRefDSOLocalEquivalentIDs map

I accidentally cleared ForwardRefDSOLocalEquivalentNames twice instead.

Differential Revision: https://reviews.llvm.org/D135315

Fix build failures from 4f6477a615d18dac6cc3aa0d3fb946191f8168c9.

[llvm][NFC] Consolidate equivalent function type parsing code into
single function

Differential Revision: https://reviews.llvm.org/D135296

[IR] Don't allow DLL storage-class and local linkage

Disallow this meaningless combination. Doing so simplifies analysis
of LLVM code w.r.t t DLL storage-class, and prevents mistakes with
DLL storag

[IR] Don't allow DLL storage-class and local linkage

Disallow this meaningless combination. Doing so simplifies analysis
of LLVM code w.r.t t DLL storage-class, and prevents mistakes with
DLL storage class.

- Change the assembler to reject DLL storage class on symbols with
local linkage.
- Change the bitcode reader to clear the DLL Storage class when the
linkage is local for auto-upgrading
- Update LangRef.

There is an existing restriction on non-default visibility and local
linkage which this is modelled on.

Differential Review: https://reviews.llvm.org/D134784

show more ...

Reland "[llvm] Support forward-referenced globals with dso_local_equivalent"

This reverts commit eef5db2c744e4799dc40ada54fdde7dbbd552807.

See https://github.com/llvm/llvm-project/issues/57815.

ds

Reland "[llvm] Support forward-referenced globals with dso_local_equivalent"

This reverts commit eef5db2c744e4799dc40ada54fdde7dbbd552807.

See https://github.com/llvm/llvm-project/issues/57815.

dso_local_equivalent would fail with an assertion on forward-referenced
globals. This is an issue that only comes up in textual IR, which is why
we've never seen this assertion with clang.

Differential Revision: https://reviews.llvm.org/D134234

show more ...

Revert "[llvm] Support forward-referenced globals with dso_local_equivalent"

This reverts commit 411020ad1c15a5f8cdbf674a2a8f845000f761e3.

One of the tests here fails on some upstream builders:
htt

Revert "[llvm] Support forward-referenced globals with dso_local_equivalent"

This reverts commit 411020ad1c15a5f8cdbf674a2a8f845000f761e3.

One of the tests here fails on some upstream builders:
https://lab.llvm.org/buildbot#builders/16/builds/35314

show more ...

[llvm] Support forward-referenced globals with dso_local_equivalent

See https://github.com/llvm/llvm-project/issues/57815.

dso_local_equivalent would fail with an assertion on forward-referenced
gl

[llvm] Support forward-referenced globals with dso_local_equivalent

See https://github.com/llvm/llvm-project/issues/57815.

dso_local_equivalent would fail with an assertion on forward-referenced
globals. This is an issue that only comes up in textual IR, which is why
we've never seen this assertion with clang.

Differential Revision: https://reviews.llvm.org/D134234

show more ...

[AArch64][SME] Fix lowering of llvm.aarch64.get.pstatesm()

A thread may not have access to SME or TPIDR2_EL0, so in order to
safely query PSTATE.SM in a streaming-compatible function, the
code shoul

[AArch64][SME] Fix lowering of llvm.aarch64.get.pstatesm()

A thread may not have access to SME or TPIDR2_EL0, so in order to
safely query PSTATE.SM in a streaming-compatible function, the
code should call `__arm_sme_state()`, as described in the ABI:

https://github.com/ARM-software/abi-aa/pull/123/commits/c2bb09c4d4ee60a5787baf1ccc7e92e67e4240b7

This means that the value of pstate.sm is:
* 0 if the function is non-streaming.
* 1 if the function has `arm_streaming` or `arm_locally_streaming`.
* evaluated at runtime by a call to __arm_sme_state() otherwise.

This patch also adds a calling convention for calls to SME support routines.

At some point we can remove the need for the llvm.aarch64.get.pstatesm() intrinsic
and use function calls (with the corresponding cc) directly instead.

Reviewed By: aemerson

Differential Revision: https://reviews.llvm.org/D131571

show more ...

[ConstantExpr] Remove fneg expression

As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179,
this removes the fneg constant expression (which is, incidentally,
the only

[ConstantExpr] Remove fneg expression

As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179,
this removes the fneg constant expression (which is, incidentally,
the only unary operator expression).

Differential Revision: https://reviews.llvm.org/D133418

show more ...

[LLParser] Allow zero-input phi nodes

Zero-input phi nodes are accepted by the verifier and bitcode reader,
but currently rejected by the IR parser. Allow them there as well.

Because phi nodes must

[LLParser] Allow zero-input phi nodes

Zero-input phi nodes are accepted by the verifier and bitcode reader,
but currently rejected by the IR parser. Allow them there as well.

Because phi nodes must have one entry for each predecessor, such
phis can only occur in blocks without predecessors, aka unreachable
code.

Usually, when removing the last predecessor from a block, we also
remove phi nodes in it. However, this is not possible for
invalidation reasons sometimes, which is why we ended up allowing
zero-entry phis at some point in the past. See 9eb2c0113dfe,
D92247 and PR48296 for context.

I've dropped the verifier unit test, because this is now covered
by the regular IR test.

This fixes at least part of https://github.com/llvm/llvm-project/issues/57446.

Differential Revision: https://reviews.llvm.org/D133000

show more ...

Remove 'no_sanitize_memtag'. Add 'sanitize_memtag'.

For MTE globals, we should have clang emit the attribute for all GV's
that it creates, and then use that in the upcoming AArch64 global
tagging IR

Remove 'no_sanitize_memtag'. Add 'sanitize_memtag'.

For MTE globals, we should have clang emit the attribute for all GV's
that it creates, and then use that in the upcoming AArch64 global
tagging IR pass. We need a positive attribute for this sanitizer (rather
than implicit sanitization of all globals) because it needs to interact
with other parts of LLVM, including:

1. Suppressing certain global optimisations (like merging),
2. Emitting extra directives by the ASM writer, and
3. Putting extra information in the symbol table entries.

While this does technically make the LLVM IR / bitcode format
non-backwards-compatible, nobody should have used this attribute yet,
because it's a no-op.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D128950

show more ...

[AsmParser] Fix a warning

This patch fixes:

llvm/lib/AsmParser/LLParser.cpp:466:34: error: moving a temporary
object prevents copy elision [-Werror,-Wpessimizing-move]

[AsmParser] Report invalid data layout more gracefully

Report this as a normal LLParser error, rather than a fatal error.

[AsmParser] Use toString() (NFC)

[InlineAsm] Improve error messages for invalid constraint strings

InlineAsm constraint string verification can fail for many reasons,
but used to always print a generic "invalid type for inline asm

[InlineAsm] Improve error messages for invalid constraint strings

InlineAsm constraint string verification can fail for many reasons,
but used to always print a generic "invalid type for inline asm
constraint string" message -- which is especially confusing if
the actual error is unrelated to the type, e.g. a failure to parse
the constraint string.

Change the verify API to return an Error with a more specific
error message, and print that in the IR parser.

show more ...

[IR] Remove support for float binop constant expressions

As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179,
this removes support for the floating-point binop constan

[IR] Remove support for float binop constant expressions

As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179,
this removes support for the floating-point binop constant expressions
fadd, fsub, fmul, fdiv and frem.

As part of this change, the C APIs LLVMConstFAdd, LLVMConstFSub,
LLVMConstFMul, LLVMConstFDiv and LLVMConstFRem are removed.
The LLVMBuild APIs should be used instead.

Differential Revision: https://reviews.llvm.org/D129478

show more ...

[LLVM] Add the support for fmax and fmin in atomicrmw instruction

This patch adds the support for `fmax` and `fmin` operations in `atomicrmw`
instruction. For now (at least in this patch), the instr

[LLVM] Add the support for fmax and fmin in atomicrmw instruction

This patch adds the support for `fmax` and `fmin` operations in `atomicrmw`
instruction. For now (at least in this patch), the instruction will be expanded
to CAS loop. There are already a couple of targets supporting the feature. I'll
create another patch(es) to enable them accordingly.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D127041

show more ...

[ConstExpr] Remove div/rem constant expressions

D128820 stopped creating div/rem constant expressions by default;
this patch removes support for them entirely.

The getUDiv(), getExactUDiv(), getSDi

[ConstExpr] Remove div/rem constant expressions

D128820 stopped creating div/rem constant expressions by default;
this patch removes support for them entirely.

The getUDiv(), getExactUDiv(), getSDiv(), getExactSDiv(), getURem()
and getSRem() on ConstantExpr are removed, and ConstantExpr::get()
now only accepts binary operators for which
ConstantExpr::isSupportedBinOp() returns true. Uses of these methods
may be replaced either by corresponding IRBuilder methods, or
ConstantFoldBinaryOpOperands (if a constant result is required).

On the C API side, LLVMConstUDiv, LLVMConstExactUDiv, LLVMConstSDiv,
LLVMConstExactSDiv, LLVMConstURem and LLVMConstSRem are removed and
corresponding LLVMBuild methods should be used.

Importantly, this also means that constant expressions can no longer
trap! This patch still keeps the canTrap() method to minimize diff --
I plan to drop it in a separate NFC patch.

Differential Revision: https://reviews.llvm.org/D129148

show more ...

[IR] Remove support for insertvalue constant expression

This removes the insertvalue constant expression, as part of
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
This is

[IR] Remove support for insertvalue constant expression

This removes the insertvalue constant expression, as part of
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
This is very similar to the extractvalue removal from D125795.
insertvalue is also not supported in bitcode, so no auto-ugprade
is necessary.

ConstantExpr::getInsertValue() can be replaced with
IRBuilder::CreateInsertValue() or ConstantFoldInsertValueInstruction(),
depending on whether a constant result is required (with the latter
being fallible).

The ConstantExpr::hasIndices() and ConstantExpr::getIndices()
methods also go away here, because there are no longer any constant
expressions with indices.

Differential Revision: https://reviews.llvm.org/D128719

show more ...

[IR] Remove support for extractvalue constant expression

This removes the extractvalue constant expression, as part of
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
extrac

[IR] Remove support for extractvalue constant expression

This removes the extractvalue constant expression, as part of
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
extractvalue is already not supported in bitcode, so we do not need
to worry about bitcode auto-upgrade.

Uses of ConstantExpr::getExtractValue() should be replaced with
IRBuilder::CreateExtractValue() (if the fact that the result is
constant is not important) or ConstantFoldExtractValueInstruction()
(if it is). Though for this particular case, it is also possible
and usually preferable to use getAggregateElement() instead.

The C API function LLVMConstExtractValue() is removed, as the
underlying constant expression no longer exists. Instead,
LLVMBuildExtractValue() should be used (which will constant fold
or create an instruction). Depending on the use-case,
LLVMGetAggregateElement() may also be used instead.

Differential Revision: https://reviews.llvm.org/D125795

show more ...

[llvm] Don't use Optional::getValue (NFC)

[llvm] Use value_or instead of getValueOr (NFC)

[AsmParser] Use default member initialization (NFC)

Identified with modernize-use-default-member-init.

Add sanitizer-specific GlobalValue attributes.

Plan is the migrate the global variable metadata for sanitizers, that's
currently carried around generally in the 'llvm.asan.globals' section,
onto the

Add sanitizer-specific GlobalValue attributes.

Plan is the migrate the global variable metadata for sanitizers, that's
currently carried around generally in the 'llvm.asan.globals' section,
onto the global variable itself.

This patch adds the attribute and plumbs it through the LLVM IR and
bitcode formats, but is a no-op other than that so far.

Reviewed By: vitalybuka, kstoimenov

Differential Revision: https://reviews.llvm.org/D126100

show more ...