[AsmParser] Remove MDSignedOrUnsignedField (NFC)

The last use was removed on Apr 18, 2020 in commit
aad3d578da0ddf6d0d3d95e5e09a32e47f6dfeb8.

[NFC] Clean up users of AttributeList::hasAttribute()

AttributeList::hasAttribute() is confusing, use clearer methods like
hasParamAttr()/hasRetAttr().

Add hasRetAttr() since it was missing from At

[NFC] Clean up users of AttributeList::hasAttribute()

AttributeList::hasAttribute() is confusing, use clearer methods like
hasParamAttr()/hasRetAttr().

Add hasRetAttr() since it was missing from AttributeList.

show more ...

[NFC] Rename AttributeList::getParam/Ret/FnAttributes() -> get*Attributes()

This is more consistent with similar methods.

[IR] Rename `comdat noduplicates` to `comdat nodeduplicate`

In the textual format, `noduplicates` means no COMDAT/section group
deduplication is performed. Therefore, if both sets of sections are re

[IR] Rename `comdat noduplicates` to `comdat nodeduplicate`

In the textual format, `noduplicates` means no COMDAT/section group
deduplication is performed. Therefore, if both sets of sections are retained, and
they happen to define strong external symbols with the same names,
there will be a duplicate definition linker error.

In PE/COFF, the selection kind lowers to `IMAGE_COMDAT_SELECT_NODUPLICATES`.
The name describes the corollary instead of the immediate semantics. The name
can cause confusion to other binary formats (ELF, wasm) which have implemented/
want to implement the "no deduplication" selection kind. Rename it to be clearer.

Reviewed By: rnk

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

show more ...

[AsmParser] Unify parsing of attributes

Continuing on from D105780, this should be the last major bit of
attribute cleanup. Currently, LLParser implements attribute parsing
for functions, parameters

[AsmParser] Unify parsing of attributes

Continuing on from D105780, this should be the last major bit of
attribute cleanup. Currently, LLParser implements attribute parsing
for functions, parameters and returns separately, enumerating all
supported (and unsupported) attributes each time. This patch
extracts the common parsing logic, and performs a check afterwards
whether the attribute is valid in the given position. Parameters
and returns are handled together, while function attributes need
slightly different logic to support attribute groups.

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

show more ...

[AttrBuilder] Make handling of type attributes more generic (NFCI)

While working on the elementtype attribute, I felt that the type
attribute handling in AttrBuilder is overly repetitive. This patch

[AttrBuilder] Make handling of type attributes more generic (NFCI)

While working on the elementtype attribute, I felt that the type
attribute handling in AttrBuilder is overly repetitive. This patch
converts the separate Type* members into an std::array<Type*>, so
that all type attribute kinds can be handled generically.

There's more room for improvement here (especially when it comes to
converting the AttrBuilder to an Attribute), but this seems like a
good starting point.

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

show more ...

Revert "[DebugInfo] Enforce implicit constraints on `distinct` MDNodes"

This reverts commit 8cd35ad854ab4458fd509447359066ea3578b494.

It breaks `TestMembersAndLocalsWithSameName.py` on GreenDragon

Revert "[DebugInfo] Enforce implicit constraints on `distinct` MDNodes"

This reverts commit 8cd35ad854ab4458fd509447359066ea3578b494.

It breaks `TestMembersAndLocalsWithSameName.py` on GreenDragon and
Mikael Holmén points out in D104827 that bitcode files created with the
patch cannot be parsed with binaries built before it.

show more ...

Place the BlockAddress type in the address space of the containing function

While this should not matter for most architectures (where the program
address space is 0), it is important for CHERI (and

Place the BlockAddress type in the address space of the containing function

While this should not matter for most architectures (where the program
address space is 0), it is important for CHERI (and therefore Arm Morello).
We use address space 200 for all of our code pointers and without this
change we assert in the SelectionDAG handling of BlockAddress nodes.

It is also useful for AVR: previously programs targeting
AVR that attempt to read their own machine code
via a pointer to a label would instead read from RAM
using a pointer relative to the the start of program flash.

Reviewed By: dylanmckay, theraven
Differential Revision: https://reviews.llvm.org/D48803

show more ...

OpaquePtr: Support i32** with --force-opaque-pointers

4506f614cb6983a16d117cf77a968608e66d7a5c fixed parsing of textual IR to
reject `ptr*`, but broke the auto-conversion of `i32**` to `ptr` with
`-

OpaquePtr: Support i32** with --force-opaque-pointers

4506f614cb6983a16d117cf77a968608e66d7a5c fixed parsing of textual IR to
reject `ptr*`, but broke the auto-conversion of `i32**` to `ptr` with
`--force-opaque-pointers`.

Get that working again by refactoring LLParser::parseType to only send
`ptr`-spelled pointers into the type suffix logic when it's the return
of a function type. This also rejects `ptr addrspace(3) addrspace(2)`,
which 1e6303e60ca5af4fbe7ca728572fd65666a98271 invadvertently started
accepting. Just the default top-level error message for the
double-addrspace since I had trouble thinking of something nice;
probably it's fine as is (it doesn't look valid the way that `ptr*`
does).

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

show more ...

[OpaquePtr] Support forward references in textual IR

Currently, LLParser will create a Function/GlobalVariable forward
reference based on the desired pointer type and then modify it when
it is decla

[OpaquePtr] Support forward references in textual IR

Currently, LLParser will create a Function/GlobalVariable forward
reference based on the desired pointer type and then modify it when
it is declared. With opaque pointers, we generally do not know the
correct type to use until we see the declaration.

Solve this by creating the forward reference with a dummy type, and
then performing a RAUW with the correct Function/GlobalVariable when
it is declared. The approach is adopted from
https://github.com/TNorthover/llvm-project/commit/b5b55963f62038319fa7a8b1b232226ba1d8ef3c.

This results in a change to the use list order, which is why we see
test changes on some module passes that are not stable under use list
reordering.

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

show more ...

[DebugInfo] Enforce implicit constraints on `distinct` MDNodes

Add UNIQUED and DISTINCT properties in Metadata.def and use them to
implement restrictions on the `distinct` property of MDNodes:

* DI

[DebugInfo] Enforce implicit constraints on `distinct` MDNodes

Add UNIQUED and DISTINCT properties in Metadata.def and use them to
implement restrictions on the `distinct` property of MDNodes:

* DIExpression can currently be parsed from IR or read from bitcode
as `distinct`, but this property is silently dropped when printing
to IR. This causes accepted IR to fail to round-trip. As DIExpression
appears inline at each use in the canonical form of IR, it cannot
actually be `distinct` anyway, as there is no syntax to describe it.
* Similarly, DIArgList is conceptually always uniqued. It is currently
restricted to only appearing in contexts where there is no syntax for
`distinct`, but for consistency it is treated equivalently to
DIExpression in this patch.
* DICompileUnit is already restricted to always being `distinct`, but
along with adding general support for the inverse restriction I went
ahead and described this in Metadata.def and updated the parser to be
general. Future nodes which have this restriction can share this
support.

The new UNIQUED property applies to DIExpression and DIArgList, and
forbids them to be `distinct`. It also implies they are canonically
printed inline at each use, rather than via MDNode ID.

The new DISTINCT property applies to DICompileUnit, and requires it to
be `distinct`.

A potential alternative change is to forbid the non-inline syntax for
DIExpression entirely, as is done with DIArgList implicitly by requiring
it appear in the context of a function. For example, we would forbid:

!named = !{!0}
!0 = !DIExpression()

Instead we would only accept the equivalent inlined version:

!named = !{!DIExpression()}

This essentially removes the ability to create a `distinct` DIExpression
by construction, as there is no syntax for `distinct` inline. If this
patch is accepted as-is, the result would be that the non-canonical
version is accepted, but the following would be an error and produce a diagnostic:

!named = !{!0}
; error: 'distinct' not allowed for !DIExpression()
!0 = distinct !DIExpression()

Also update some documentation to consistently use the inline syntax for
DIExpression, and to describe the restrictions on `distinct` for nodes
where applicable.

Reviewed By: StephenTozer, t-tye

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

show more ...

OpaquePtr: Reject 'ptr*' again when parsing textual IR

Bring back the testcase dropped in
1e6303e60ca5af4fbe7ca728572fd65666a98271 and get it passing by checking
explicitly for `ptr*` in LLParser. U

OpaquePtr: Reject 'ptr*' again when parsing textual IR

Bring back the testcase dropped in
1e6303e60ca5af4fbe7ca728572fd65666a98271 and get it passing by checking
explicitly for `ptr*` in LLParser. Uses `Type::isOpaquePointerTy()` from
ad4bb8280952c2cacf497e30560ee94c119b36e0.

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

show more ...

[IR] Add Type::isOpaquePointerTy() helper (NFC)

Shortcut to check for opaque pointers without a cast to PointerType.

[OpaquePtr] Allow alias to opaque pointer

By relaxing the LLParser pointer type assertion.

[OpaquePtr] Support call instruction

Add support for call of opaque pointer, currently only possible for
indirect calls.

This requires a bit of special casing in LLParser, as calls do not
specify t

[OpaquePtr] Support call instruction

Add support for call of opaque pointer, currently only possible for
indirect calls.

This requires a bit of special casing in LLParser, as calls do not
specify the callee operand type explicitly.

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

show more ...

[LLParser] Remove special handling for call address space

Spin-off from D104740: I don't think this special handling is needed
anymore. Calls in textual IR are annotated with addrspace(N) (which
def

[LLParser] Remove special handling for call address space

Spin-off from D104740: I don't think this special handling is needed
anymore. Calls in textual IR are annotated with addrspace(N) (which
defaults to the program address space from data layout) and specifies
the expected pointer address space of the callee. There is no need
to special-case the program address space on top of that, as it
already is the default expected address space, and we shouldn't
allow use of the program address space if the call was explicitly
annotated with some other address space.

The IsCall parameter is retained because it will be used again soon.

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

show more ...

[OpaquePtr] Support opaque constant expression GEP

Adjust assertions to use isOpaqueOrPointeeTypeMatches() and make
it return an opaque pointer result for an opaque base pointer. We
also need to enu

[OpaquePtr] Support opaque constant expression GEP

Adjust assertions to use isOpaqueOrPointeeTypeMatches() and make
it return an opaque pointer result for an opaque base pointer. We
also need to enumerate the element type, as it is no longer
implicitly enumerated through the pointer type.

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

show more ...

[LLParser] Remove outdated deplibs

The comment mentions deplibs should be removed in 4.0. Removing it in this patch.

Reviewed By: compnerd, dexonsmith, lattner

Differential Revision: https://revie

[LLParser] Remove outdated deplibs

The comment mentions deplibs should be removed in 4.0. Removing it in this patch.

Reviewed By: compnerd, dexonsmith, lattner

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

show more ...

Fix some -Wunused-but-set-variable in -DLLVM_ENABLE_ASSERTIONS=off build

[OpaquePtr] Make atomicrmw work with opaque pointers

FullTy is only necessary when we need to figure out what type an
instruction works with given a pointer's pointee type. However, we just
end up u

[OpaquePtr] Make atomicrmw work with opaque pointers

FullTy is only necessary when we need to figure out what type an
instruction works with given a pointer's pointee type. However, we just
end up using the value operand's type, so FullTy isn't necessary.

Reviewed By: dblaikie

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

show more ...

Revert "[OpaquePtr] Make atomicrmw work with opaque pointers"

This reverts commit 0bebda17bea38785c90a6fec3ca01cf74eb78b7c.

Causing "Invalid record" errors.

[SanitizeCoverage] Add support for NoSanitizeCoverage function attribute

We really ought to support no_sanitize("coverage") in line with other
sanitizers. This came up again in discussions on the Li

[SanitizeCoverage] Add support for NoSanitizeCoverage function attribute

We really ought to support no_sanitize("coverage") in line with other
sanitizers. This came up again in discussions on the Linux-kernel
mailing lists, because we currently do workarounds using objtool to
remove coverage instrumentation. Since that support is only on x86, to
continue support coverage instrumentation on other architectures, we
must support selectively disabling coverage instrumentation via function
attributes.

Unfortunately, for SanitizeCoverage, it has not been implemented as a
sanitizer via fsanitize= and associated options in Sanitizers.def, but
rolls its own option fsanitize-coverage. This meant that we never got
"automatic" no_sanitize attribute support.

Implement no_sanitize attribute support by special-casing the string
"coverage" in the NoSanitizeAttr implementation. To keep the feature as
unintrusive to existing IR generation as possible, define a new negative
function attribute NoSanitizeCoverage to propagate the information
through to the instrumentation pass.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=49035

Reviewed By: vitalybuka, morehouse

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

show more ...

[Verifier] Move some atomicrmw/cmpxchg checks to instruction creation

These checks already exist as asserts when creating the corresponding
instruction. Anybody creating these instructions already n

[Verifier] Move some atomicrmw/cmpxchg checks to instruction creation

These checks already exist as asserts when creating the corresponding
instruction. Anybody creating these instructions already need to take
care to not break these checks.

Move the checks for success/failure ordering in cmpxchg from the
verifier to the LLParser and BitcodeReader plus an assert.

Add some tests for cmpxchg ordering. The .bc files are created from the
.ll files with an llvm-as with these checks disabled.

Reviewed By: dblaikie

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

show more ...

[OpaquePtr] Make atomicrmw work with opaque pointers

FullTy is only necessary when we need to figure out what type an
instruction works with given a pointer's pointee type. However, we just
end up u

[OpaquePtr] Make atomicrmw work with opaque pointers

FullTy is only necessary when we need to figure out what type an
instruction works with given a pointer's pointee type. However, we just
end up using the value operand's type, so FullTy isn't necessary.

Reviewed By: dblaikie

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

show more ...

[OpaquePtr] Make cmpxchg work with opaque pointers

Reviewed By: dblaikie

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