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

[BitcodeReader] Validate Strtab before accessing.

This fixes a crash with invalid bitcode files that have records
referencing names in Strtab, but Strtab is not present or the index is
out-of-bounds

[BitcodeReader] Validate Strtab before accessing.

This fixes a crash with invalid bitcode files that have records
referencing names in Strtab, but Strtab is not present or the index is
out-of-bounds.

This fixes the following clusterfuzz issue:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29895

Reviewed By: arsenm

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

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

Move some code under NDEBUG from D103135

[OpaquePtr] Remove existing support for forward compatibility

It assumes that PointerType will keep having an optional pointee type,
but we'd like to remove the pointee type in PointerType at some p

[OpaquePtr] Remove existing support for forward compatibility

It assumes that PointerType will keep having an optional pointee type,
but we'd like to remove the pointee type in PointerType at some point.

I feel like the current implementation could be simplified anyway,
although perhaps I'm underestimating the amount of work needed
throughout BitcodeReader.

We will still need a side table to keep track of pointee types. This
will be reimplemented at some point.

This is essentially a revert of a4771e9d (which doesn't look like it was
reviewed anyway).

Reviewed By: dblaikie

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

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] Create new bitcode encoding for atomicrmw

Since the opaque pointer type won't contain the pointee type, we need to
separately encode the value type for an atomicrmw.

Emit this new code

[OpaquePtr] Create new bitcode encoding for atomicrmw

Since the opaque pointer type won't contain the pointee type, we need to
separately encode the value type for an atomicrmw.

Emit this new code for atomicrmw.

Handle this new code and the old one in the bitcode reader.

Reviewed By: dblaikie

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

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

[IR][AutoUpgrade] Drop alignment from non-pointer parameters and returns

This is a follow-up of D102201. After some discussion, it is a better idea
to upgrade all invalid uses of alignment attribute

[IR][AutoUpgrade] Drop alignment from non-pointer parameters and returns

This is a follow-up of D102201. After some discussion, it is a better idea
to upgrade all invalid uses of alignment attributes on function return
values and parameters, not just limited to void function return types.

Reviewed By: jdoerfert

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

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 GEPs work with opaque pointers

No verifier changes needed, the verifier currently doesn't check that
the pointer operand's pointee type matches the GEP type. There is a
similar chec

[OpaquePtr] Make GEPs work with opaque pointers

No verifier changes needed, the verifier currently doesn't check that
the pointer operand's pointee type matches the GEP type. There is a
similar check in GetElementPtrInst::Create() though.

Reviewed By: dblaikie

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

show more ...

[OpaquePtr] Make loads and stores work with opaque pointers

Don't check that types match when the pointer operand is an opaque
pointer.

I would separate the Assembler and Verifier changes, but
veri

[OpaquePtr] Make loads and stores work with opaque pointers

Don't check that types match when the pointer operand is an opaque
pointer.

I would separate the Assembler and Verifier changes, but
verify-uselistorder in the Assembler test ends up running the verifier.

Reviewed By: dblaikie

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

show more ...

IR+AArch64: add a "swiftasync" argument attribute.

This extends any frame record created in the function to include that
parameter, passed in X22.

The new record looks like [X22, FP, LR] in memory,

IR+AArch64: add a "swiftasync" argument attribute.

This extends any frame record created in the function to include that
parameter, passed in X22.

The new record looks like [X22, FP, LR] in memory, and FP is stored with 0b0001
in bits 63:60 (CodeGen assumes they are 0b0000 in normal operation). The effect
of this is that tools walking the stack should expect to see one of three
values there:

* 0b0000 => a normal, non-extended record with just [FP, LR]
* 0b0001 => the extended record [X22, FP, LR]
* 0b1111 => kernel space, and a non-extended record.

All other values are currently reserved.

If compiling for arm64e this context pointer is address-discriminated with the
discriminator 0xc31a and the DB (process-specific) key.

There is also an "i8** @llvm.swift.async.context.addr()" intrinsic providing
front-ends access to this slot (and forcing its creation initialized to nullptr
if necessary).

show more ...

[IR] Introduce the opaque pointer type

The opaque pointer type is essentially just a normal pointer type with a
null pointee type.

This also adds support for the opaque pointer type to the bitcode

[IR] Introduce the opaque pointer type

The opaque pointer type is essentially just a normal pointer type with a
null pointee type.

This also adds support for the opaque pointer type to the bitcode
reader/writer, as well as to textual IR.

To avoid confusion with existing pointer types, we disallow creating a
pointer to an opaque pointer.

Opaque pointer types should not be widely used at this point since many
parts of LLVM still do not support them. The next steps are to add some
very simple use cases of opaque pointers to make sure they work, then
start pretending that all pointers are opaque pointers and see what
breaks.

https://lists.llvm.org/pipermail/llvm-dev/2021-May/150359.html

Reviewed By: dblaikie, dexonsmith, pcc

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

show more ...

Support unwinding from inline assembly

I've taken the following steps to add unwinding support from inline assembly:

1) Add a new `unwind` "attribute" (like `sideeffect`) to the asm syntax:

```
in

Support unwinding from inline assembly

I've taken the following steps to add unwinding support from inline assembly:

1) Add a new `unwind` "attribute" (like `sideeffect`) to the asm syntax:

```
invoke void asm sideeffect unwind "call thrower", "~{dirflag},~{fpsr},~{flags}"()
to label %exit unwind label %uexit
```

2.) Add Bitcode writing/reading support + LLVM-IR parsing.

3.) Emit EHLabels around inline assembly lowering (SelectionDAGBuilder + GlobalISel) when `InlineAsm::canThrow` is enabled.

4.) Tweak InstCombineCalls/InlineFunction pass to not mark inline assembly "calls" as nounwind.

5.) Add clang support by introducing a new clobber: "unwind", which lower to the `canThrow` being enabled.

6.) Don't allow unwinding callbr.

Reviewed By: Amanieu

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

show more ...

[IR][AutoUpgrade] Drop align attribute from void return types

Since D87304, `align` become an invalid attribute on none pointer types and
verifier will reject bitcode that has invalid `align` attrib

[IR][AutoUpgrade] Drop align attribute from void return types

Since D87304, `align` become an invalid attribute on none pointer types and
verifier will reject bitcode that has invalid `align` attribute.

The problem is before the change, DeadArgumentElimination can easily
turn a pointer return type into a void return type without removing
`align` attribute. Teach Autograde to remove invalid `align` attribute
from return types to maintain bitcode compatibility.

rdar://77022993

Reviewed By: dexonsmith

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

show more ...

Reapply "OpaquePtr: Turn inalloca into a type attribute"

This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.

Revert "Reapply "OpaquePtr: Turn inalloca into a type attribute""

Reverting because test 'Bindings/Go/go.test' is failing on most
buildbots.

This reverts commit fc9df309917e57de704f3ce4372138a8d4a2

Revert "Reapply "OpaquePtr: Turn inalloca into a type attribute""

Reverting because test 'Bindings/Go/go.test' is failing on most
buildbots.

This reverts commit fc9df309917e57de704f3ce4372138a8d4a23d7a.

show more ...

Reapply "OpaquePtr: Turn inalloca into a type attribute"

This reverts commit 20d5c42e0ef5d252b434bcb610b04f1cb79fe771.

Revert "OpaquePtr: Turn inalloca into a type attribute"

This reverts commit 4fefed65637ec46c8c2edad6b07b5569ac61e9e5.
Broke check-clang everywhere.

OpaquePtr: Turn inalloca into a type attribute

I think byval/sret and the others are close to being able to rip out
the code to support the missing type case. A lot of this code is
shared with inall

OpaquePtr: Turn inalloca into a type attribute

I think byval/sret and the others are close to being able to rip out
the code to support the missing type case. A lot of this code is
shared with inalloca, so catch this up to the others so that can
happen.

show more ...

[IR] Add vscale_range IR function attribute

This attribute represents the minimum and maximum values vscale can
take. For now this attribute is not hooked up to anything during
codegen, this will be

[IR] Add vscale_range IR function attribute

This attribute represents the minimum and maximum values vscale can
take. For now this attribute is not hooked up to anything during
codegen, this will be added in the future when such codegen is
considered stable.

Additionally hook up the -msve-vector-bits=<x> clang option to emit this
attribute.

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

show more ...

[llvm][Bitcode] Add bitcode reader/writer for DSOLocalEquivalent

This is necessary for compilation with [thin]lto.

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