[Core] Allow `hasAddressTaken` to ignore "casted direct calls"

A direct call to a function casted to a different type is still not
really an address taken event. We allow the user to opt out of thes

[Core] Allow `hasAddressTaken` to ignore "casted direct calls"

A direct call to a function casted to a different type is still not
really an address taken event. We allow the user to opt out of these
now.

Reviewed By: arsenm

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

show more ...

[Clang][LoongArch] Use the ClangBuiltin class to automatically generate support for CBE and CFE

Fixed the type modifier (L->W), removed redundant feature checking code
since the feature has already

[Clang][LoongArch] Use the ClangBuiltin class to automatically generate support for CBE and CFE

Fixed the type modifier (L->W), removed redundant feature checking code
since the feature has already been checked in `EmitBuiltinExpr`. And
Cleaned up unused diagnostic information.

Reviewed By: SixWeining

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

show more ...

Stop using legacy helpers indicating typed pointer types. NFC

Since we no longer support typed LLVM IR pointer types, the code can
be simplified into for example using PointerType::get directly inst

Stop using legacy helpers indicating typed pointer types. NFC

Since we no longer support typed LLVM IR pointer types, the code can
be simplified into for example using PointerType::get directly instead
of using Type::getInt8PtrTy and Type::getInt32PtrTy etc.

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

show more ...

[llvm] Remove uses of isOpaqueOrPointeeTypeEquals() (NFC)

[llvm] Remove uses of getNonOpaquePointerElementType() (NFC)

[IR] Remove LLVMPointerToElt and LLVMAnyPointerToElt intrinsic types (NFC)

With opaque pointers, LLVMPointerToElt can be replaced by llvm_ptr_ty
and LLVMAnyPointerToElt by llvm_anyptr_ty.

This stil

[IR] Remove LLVMPointerToElt and LLVMAnyPointerToElt intrinsic types (NFC)

With opaque pointers, LLVMPointerToElt can be replaced by llvm_ptr_ty
and LLVMAnyPointerToElt by llvm_anyptr_ty.

This still leaves LLVMVectorOfAnyPointersToElt, where we can't just
replace with an existing IIT descriptor.

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

show more ...

[IR] Remove LLVMPointerTo intrinsic type (NFC)

With opaque pointers, this is equivalent to llvm_ptr_ty. However,
this particular type was actually completely unused.

[IR] Partially remove pointer element types from intrinsic signatures (NFC)

As typed pointers are no longer supported, we should no longer
specify element types in intrinsic signatures.

The only me

[IR] Partially remove pointer element types from intrinsic signatures (NFC)

As typed pointers are no longer supported, we should no longer
specify element types in intrinsic signatures.

The only meaningful pointer types are now:

llvm_ptr_ty -> ptr
llvm_anyptr_ty -> ptr addrspace(any)
LLVMQualPointerType<N> -> ptr addrspace(N)

This is only "partially" because we also have a bunch of special
IIT descriptors like LLVMPointerTo, LLVMPointerToElt and
LLVMAnyPointerToElt, which I'll leave for a later revision.

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

show more ...

[AArch64][SME2/SVE2p1] Add predicate-as-counter intrinsics for ptrue/cntp

These intrinsics are used to implement:
* svptrue_c8(), svptrue_c16(), etc.
* svcntp_c8(svcount_t pnn, uint64_t vl), svcntp_

[AArch64][SME2/SVE2p1] Add predicate-as-counter intrinsics for ptrue/cntp

These intrinsics are used to implement:
* svptrue_c8(), svptrue_c16(), etc.
* svcntp_c8(svcount_t pnn, uint64_t vl), svcntp_c16(...), etc.

As described in https://github.com/ARM-software/acle/pull/217

Reviewed By: david-arm

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

show more ...

LangRef: Add "dynamic" option to "denormal-fp-math"

This is stricter than the default "ieee", and should probably be the
default. This patch leaves the default alone. I can change this in a
future p

LangRef: Add "dynamic" option to "denormal-fp-math"

This is stricter than the default "ieee", and should probably be the
default. This patch leaves the default alone. I can change this in a
future patch.

There are non-reversible transforms I would like to perform which are
legal under IEEE denormal handling, but illegal with flushing zero
behavior. Namely, conversions between llvm.is.fpclass and fcmp with
zeroes.

Under "ieee" handling, it is legal to translate between
llvm.is.fpclass(x, fcZero) and fcmp x, 0.

Under "preserve-sign" handling, it is legal to translate between
llvm.is.fpclass(x, fcSubnormal|fcZero) and fcmp x, 0.

I would like to compile and distribute some math library functions in
a mode where it's callable from code with and without denormals
enabled, which requires not changing the compares with denormals or
zeroes.

If an IEEE function transforms an llvm.is.fpclass call into an fcmp 0,
it is no longer possible to call the function from code with denormals
enabled, or write an optimization to move the function into a denormal
flushing mode. For the original function, if x was a denormal, the
class would evaluate to false. If the function compiled with denormal
handling was converted to or called from a preserve-sign function, the
fcmp now evaluates to true.

This could also be of use for strictfp handling, where code may be
changing the denormal mode.

Alternative name could be "unknown".

Replaces the old AMDGPU custom inlining logic with more conservative
logic which tries to permit inlining for callees with dynamic handling
and avoids inlining other mismatched modes.

show more ...

Migrate `IIT_Info` into `Intrinsics.td`

- Define `IIT_Info` in `Intrinsics.td`
- Implement `EmitIITInfo` in `IntrinsicEmitter.cpp`
- Use generated `IIT_Info` in `Function.cpp`

Depends on D145

Migrate `IIT_Info` into `Intrinsics.td`

- Define `IIT_Info` in `Intrinsics.td`
- Implement `EmitIITInfo` in `IntrinsicEmitter.cpp`
- Use generated `IIT_Info` in `Function.cpp`

Depends on D145873 and D146179

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

show more ...

IR: Add nofpclass parameter attribute

This carries a bitmask indicating forbidden floating-point value kinds
in the argument or return value. This will enable interprocedural
-ffinite-math-only opti

IR: Add nofpclass parameter attribute

This carries a bitmask indicating forbidden floating-point value kinds
in the argument or return value. This will enable interprocedural
-ffinite-math-only optimizations. This is primarily to cover the
no-nans and no-infinities cases, but also covers the other floating
point classes for free. Textually, this provides a number of names
corresponding to bits in FPClassTest, e.g.

call nofpclass(nan inf) @must_be_finite()
call nofpclass(snan) @cannot_be_snan()

This is more expressive than the existing nnan and ninf fast math
flags. As an added bonus, you can represent fun things like nanf:

declare nofpclass(inf zero sub norm) float @only_nans()

Compared to nnan/ninf:
- Can be applied to individual call operands as well as the return value
- Can distinguish signaling and quiet nans
- Distinguishes the sign of infinities
- Can be safely propagated since it doesn't imply anything about
other operands.
- Does not apply to FP instructions; it's not a flag

This is one step closer to being able to retire "no-nans-fp-math" and
"no-infs-fp-math". The one remaining situation where we have no way to
represent no-nans/infs is for loads (if we wanted to solve this we
could introduce !nofpclass metadata, following along with
noundef/!noundef).

This is to help simplify the GPU builtin math library
distribution. Currently the library code has explicit finite math only
checks, read from global constants the compiler driver needs to set
based on the compiler flags during linking. We end up having to
internalize the library into each translation unit in case different
linked modules have different math flags. By propagating known-not-nan
and known-not-infinity information, we can automatically prune the
edge case handling in most functions if the function is only reached
from fast math uses.

show more ...

[NFC] Remove Function::getParamAlignment

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

[CallGraph][FIX] Ensure generic intrinsics are represented in the CG

Intrinsics have historically been excluded from the call graph with an
exception of 3 special ones added at some point. This mean

[CallGraph][FIX] Ensure generic intrinsics are represented in the CG

Intrinsics have historically been excluded from the call graph with an
exception of 3 special ones added at some point. This meant that passes
depending on the call graph needed to handle intrinsics explicitly as
the underlying assumption, namely that intrinsics can't call or modify
things, doesn't hold. We are slowly moving away from special handling of
intrinsics, or at least towards explicitly checking what intrinsics we
want to handle differently.

This patch:
- Includes most intrinsics in the call graph. Debug intrinsics are
still excluded.
- Removes the special handling of intrinsics in the GlobalsAA pass.
- Removes the `IntrinsicInst::isLeaf` method.

Properly
Fixes: https://github.com/llvm/llvm-project/issues/52706

See also:
https://discourse.llvm.org/t/intrinsics-are-not-special-stop-pretending-i-mean-it/67545

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

show more ...

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).

Per reviewers' comment, some useless makeArrayRef have been removed in the process.

This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.

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

show more ...

[IR] Add a target extension type to LLVM.

Target-extension types represent types that need to be preserved through
optimization, but otherwise are not introspectable by target-independent
optimizati

[IR] Add a target extension type to LLVM.

Target-extension types represent types that need to be preserved through
optimization, but otherwise are not introspectable by target-independent
optimizations. This patch doesn't add any uses of these types by an existing
backend, it only provides basic infrastructure such that these types would work
correctly.

Reviewed By: nikic, barannikov88

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

show more ...

Function: Respect IgnoreLLVMUsed with addrspacecasted functions

Try to respect IgnoreLLVMUsed if the function was addrspacecasted to
match llvm.used's type.

[IR] Adds Function::erase() for erasing a range of basic blocks

This is part of a series of patches that aim at making Function::getBasicBlockList() private.

Differential Revision: https://reviews.

[IR] Adds Function::erase() for erasing a range of basic blocks

This is part of a series of patches that aim at making Function::getBasicBlockList() private.

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

show more ...

Fixes EXPENSIVE_CHECKS build failure caused by 7b684119abc7d94bad47ec0b97b35598fac412d3

[IR] Adds Function::splice() member functions

This is part of a series of patches that aim at making Function::getBasicBlockList() private.

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

Attributes: Add function getter to parse integer string attributes

The most common case for string attributes parses them as integers. We
don't have a convenient way to do this, and as a result we h

Attributes: Add function getter to parse integer string attributes

The most common case for string attributes parses them as integers. We
don't have a convenient way to do this, and as a result we have
inconsistent missing attribute and invalid attribute handling
scattered around. We also have inconsistent radix usage to
getAsInteger; some places use the default 0 and others use base 10.

Update a few of the uses, but there are quite a lot of these.

show more ...

Don't include None.h (NFC)

I've converted all known uses of None to std::nullopt, so we no longer
need to include None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

Don't include None.h (NFC)

I've converted all known uses of None to std::nullopt, so we no longer
need to include None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

CallGraph: Fix IgnoreAssumeLikeCalls option to Function::hasAddressTaken

This was added in 29e2d9461a91b and likely never worked in a useful
way.

The test added for it fails when converted to opaqu

CallGraph: Fix IgnoreAssumeLikeCalls option to Function::hasAddressTaken

This was added in 29e2d9461a91b and likely never worked in a useful
way.

The test added for it fails when converted to opaque pointers, since
the lifetime intrinsic now directly uses the address. The code was
only trying to handle a user indirectly through a bitcast
instruction. That would never have been useful; a bitcast of a global
value would be folded to a ConstantExpr cast.

I also don't understand why it was special casing use_empty on the
cast. Relax the check to be either BitCastOperator or
AddrSpaceCastOperator. In practice, BitCastOperator won't appear
today.

I believe the change in parallel_deletion_cg_update is a correct
improvement but I didn't fully follow it. .omp_outlined..0 is used in
a constant expression cast to a call which ends up getting deleted.

show more ...

[IR] llvm::Optional => std::optional

Many llvm/IR/* files have been migrated by other contributors.
This migrates most remaining files.

[IR] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manu

[IR] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...