[NFC] Use Optional<ProfileCount> to model invalid counts

ProfileCount could model invalid values, but a user had no indication
that the getCount method could return bogus data. Optional<ProfileCount

[NFC] Use Optional<ProfileCount> to model invalid counts

ProfileCount could model invalid values, but a user had no indication
that the getCount method could return bogus data. Optional<ProfileCount>
addresses that, because the user must dereference the optional. In
addition, the patch removes concept duplication.

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

show more ...

[PowerPC] Implement longdouble pack/unpack builtins

Implement two builtins to pack/unpack IBM extended long double float,
according to GCC 'Basic PowerPC Builtin Functions Available ISA 2.05'.

Revi

[PowerPC] Implement longdouble pack/unpack builtins

Implement two builtins to pack/unpack IBM extended long double float,
according to GCC 'Basic PowerPC Builtin Functions Available ISA 2.05'.

Reviewed By: jsji

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

show more ...

Reland [IR] Increase max alignment to 4GB

Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bi

Reland [IR] Increase max alignment to 4GB

Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945.

This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits.
We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now.

The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field.

Updating clang's max allowed alignment will come in a future patch.

Reviewed By: hans

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

show more ...

[IR] Remove unused parameter (NFC)

[OpaquePtr] Forbid mixing typed and opaque pointers

Currently, opaque pointers are supported in two forms: The
-force-opaque-pointers mode, where all pointers are opaque and
typed pointers do not ex

[OpaquePtr] Forbid mixing typed and opaque pointers

Currently, opaque pointers are supported in two forms: The
-force-opaque-pointers mode, where all pointers are opaque and
typed pointers do not exist. And as a simple ptr type that can
coexist with typed pointers.

This patch removes support for the mixed mode. You either get
typed pointers, or you get opaque pointers, but not both. In the
(current) default mode, using ptr is forbidden. In -opaque-pointers
mode, all pointers are opaque.

The motivation here is that the mixed mode introduces additional
issues that don't exist in fully opaque mode. D105155 is an example
of a design problem. Looking at D109259, it would probably need
additional work to support mixed mode (e.g. to generate GEPs for
typed base but opaque result). Mixed mode will also end up
inserting many casts between i8* and ptr, which would require
significant additional work to consistently avoid.

I don't think the mixed mode is particularly valuable, as it
doesn't align with our end goal. The only thing I've found it to
be moderately useful for is adding some opaque pointer tests in
between typed pointer tests, but I think we can live without that.

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

show more ...

[ObjC][ARC] Use the addresses of the ARC runtime functions instead of
integer 0/1 for the operand of bundle "clang.arc.attachedcall"

https://reviews.llvm.org/D102996 changes the operand of bundle
"c

[ObjC][ARC] Use the addresses of the ARC runtime functions instead of
integer 0/1 for the operand of bundle "clang.arc.attachedcall"

https://reviews.llvm.org/D102996 changes the operand of bundle
"clang.arc.attachedcall". This patch makes changes to llvm that are
needed to handle the new IR.

This should make it easier to understand what the IR is doing and also
simplify some of the passes as they no longer have to translate the
integer values to the runtime functions.

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

show more ...

Add missing overloads for Function::addRetAttr(s)

[NFC] Rename attribute methods that work with indexes

This is part one of a couple of patches to fully rename these methods.

I've made the mistake of assuming that these indexes are for parameters

[NFC] Rename attribute methods that work with indexes

This is part one of a couple of patches to fully rename these methods.

I've made the mistake of assuming that these indexes are for parameters
multiple times, but actually they're based off of a weird indexing
scheme AttributeList::AttrIndex where 0 is the return value and ~0 is
the function. Hopefully renaming these methods will make this clearer.
Ideally users should use more specific methods like
AttributeList::getFnAttr().

This patch simply adds the name that we want in the end. This is so the
removal of the methods with the original names happens in a separate
change to make it easier for downstream users.

This touches all relevant methods in AttributeList, CallBase, and Function.

Reviewed By: rnk

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

show more ...

[NFC] Remove some unused functions

Add some Function method definitions accidentally removed

In cc327bd5231126006b4177b8ce0946ce52e2f645.

[NFC] Cleanup attribute methods in Function

[NFC] Migrate some callers away from Function/AttributeLists methods that take an index

These methods can be confusing.

[NFC] Remove/replace some confusing attribute getters on Function

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

This is more consistent with similar methods.

[NFC] Remove AttributeList::hasParamAttribute()

It's the same as AttributeList::hasParamAttr().

[Attributes] Clean up handling of UB implying attributes (NFC)

Rather than adding methods for dropping these attributes in
various places, add a function that returns an AttrBuilder with
these attri

[Attributes] Clean up handling of UB implying attributes (NFC)

Rather than adding methods for dropping these attributes in
various places, add a function that returns an AttrBuilder with
these attributes, which can then be used with existing methods
for dropping attributes. This is with an eye on D104641, which
also needs to drop them from returns, not just parameters.

Also be more explicit about the semantics of the method in the
documentation. Refer to UB rather than Undef, which is what this
is actually about.

show more ...

[remangleIntrinsicFunction] Detect and resolve name clash

It is possible that the remangled name for an intrinsic already exists with a different (and wrong) prototype within the module.
As the bitc

[remangleIntrinsicFunction] Detect and resolve name clash

It is possible that the remangled name for an intrinsic already exists with a different (and wrong) prototype within the module.
As the bitcode reader keeps both versions of all remangled intrinsics around for a longer time, this can result in a
crash, as can be seen in https://bugs.llvm.org/show_bug.cgi?id=50923

This patch makes 'remangleIntrinsicFunction' aware of this situation. When it is detected, it moves the version with the wrong prototype to a different name. That version will be removed anyway once the module is completely loaded.

With thanks to @asbirlea for reporting this issue when trying out an lto build with the full restrict patches, and @efriedma for suggesting a sane resolution mechanism.

Reviewed By: apilipenko

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

show more ...

[OpaquePtr] Support VecOfAnyPtrsToElt intrinsics

In this case the pointer type is part of the mangled name, so we
can allow on opaque pointer outside --force-opaque-pointers mode
as well.

[OpaquePtr] Support opaque pointers in intrinsic type check

This adds support for opaque pointers in intrinsic type checks
of IIT kind Pointer and PtrToElt.

This is less straight-forward than it mi

[OpaquePtr] Support opaque pointers in intrinsic type check

This adds support for opaque pointers in intrinsic type checks
of IIT kind Pointer and PtrToElt.

This is less straight-forward than it might initially seem, because
we should only accept opaque pointers here in --force-opaque-pointers
mode. Otherwise, there would be more than one valid type signature
for a given intrinsic name.

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

show more ...

[OpaquePtr] Mangle intrinsics with opaque pointers arguments

Mangling intrinsics with opaque pointer arguments using "op"+{address space}.

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

Intrinsic::getName: require a Module argument

Ensure that we provide a `Module` when checking if a rename of an intrinsic is necessary.

This fixes the issue that was detected by https://bugs.chromi

Intrinsic::getName: require a Module argument

Ensure that we provide a `Module` when checking if a rename of an intrinsic is necessary.

This fixes the issue that was detected by https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32288
(as mentioned by @fhahn), after committing D91250.

Note that the `LLVMIntrinsicCopyOverloadedName` is being deprecated in favor of `LLVMIntrinsicCopyOverloadedName2`.

Reviewed By: nikic

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

show more ...

[NFC][OpaquePtr] Make getMemoryParamAllocType() compatible with opaque pointers

These ABI attributes now always require the type parameter.

sret was missing from the first set of checks but was cov

[NFC][OpaquePtr] Make getMemoryParamAllocType() compatible with opaque pointers

These ABI attributes now always require the type parameter.

sret was missing from the first set of checks but was covered by the
second set.

show more ...

Fix non-global-value-max-name-size not considered by LLParser

`non-global-value-max-name-size` is used by `Value` to cap the length of local value name. However, this flag is not considered by `LLPa

Fix non-global-value-max-name-size not considered by LLParser

`non-global-value-max-name-size` is used by `Value` to cap the length of local value name. However, this flag is not considered by `LLParser`, which leads to unexpected `use of undefined value error`. The fix is to move the responsibility of capping the length to `ValueSymbolTable`.

The test is the one provided by [[ https://bugs.llvm.org/show_bug.cgi?id=45899 | Mikael in the bug report ]].

Reviewed By: mehdi_amini

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

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

[IR][sanitizer] Add module flag "frame-pointer" and set it for cc1 -mframe-pointer={non-leaf,all}

The Linux kernel objtool diagnostic `call without frame pointer save/setup`
arise in multiple instru

[IR][sanitizer] Add module flag "frame-pointer" and set it for cc1 -mframe-pointer={non-leaf,all}

The Linux kernel objtool diagnostic `call without frame pointer save/setup`
arise in multiple instrumentation passes (asan/tsan/gcov). With the mechanism
introduced in D100251, it's trivial to respect the command line
-m[no-]omit-leaf-frame-pointer/-f[no-]omit-frame-pointer, so let's do it.

Fix: https://github.com/ClangBuiltLinux/linux/issues/1236 (tsan)
Fix: https://github.com/ClangBuiltLinux/linux/issues/1238 (asan)

Also document the function attribute "frame-pointer" which is long overdue.

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

show more ...