[AutoUpgrade] Fix remangling when upgrading struct return type

This was remangling the old function rather than the new one, and
could result in failures when we were performing both a struct
return

[AutoUpgrade] Fix remangling when upgrading struct return type

This was remangling the old function rather than the new one, and
could result in failures when we were performing both a struct
return upgrade and an opaque pointer upgrade.

(cherry picked from commit c8938809d155682ef5eec170897b8c26b8cbf3ea)

show more ...

[Bitcode] Restore bitcast expression auto-upgrade

Restore the autoupgrade from bitcast to ptrtoint+inttoptr, which
was lost as part of D127729.

This fixes the backwards compatibility issue noted in

[Bitcode] Restore bitcast expression auto-upgrade

Restore the autoupgrade from bitcast to ptrtoint+inttoptr, which
was lost as part of D127729.

This fixes the backwards compatibility issue noted in:
https://reviews.llvm.org/D127729#inline-1236519

show more ...

[IR] Move vector.insert/vector.extract out of experimental namespace

These intrinsics are now fundemental for SVE code generation and have been
present for a year and a half, hence move them out of

[IR] Move vector.insert/vector.extract out of experimental namespace

These intrinsics are now fundemental for SVE code generation and have been
present for a year and a half, hence move them out of the experimental
namespace.

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

show more ...

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

[ObjCARC] Drop nullary clang.arc.attachedcall bundles in autoupgrade.

In certain use-cases, these can be emitted by old compilers, but the
operand is now always required. These are only used for op

[ObjCARC] Drop nullary clang.arc.attachedcall bundles in autoupgrade.

In certain use-cases, these can be emitted by old compilers, but the
operand is now always required. These are only used for optimizations,
so it's safe to drop them if they happen to have the now-invalid format.
The semantically-required call is already a separate instruction.

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

show more ...

[AutoUpgrade] Don't lose attributes when upgrading mem intrinsics

The original AutoUpgrade code from 1e68724d24ba38de7c7cdb2e1939d78c8b37cc0d
did not retain existing attributes. I noticed this in so

[AutoUpgrade] Don't lose attributes when upgrading mem intrinsics

The original AutoUpgrade code from 1e68724d24ba38de7c7cdb2e1939d78c8b37cc0d
did not retain existing attributes. I noticed this in some downstream test
cases, but it turns out there are also two affected testcase upstream.

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

show more ...

Support the min of module flags when linking, use for AArch64 BTI/PAC-RET

LTO objects might compiled with different `mbranch-protection` flags which will cause an error in the linker.
Such a setup i

Support the min of module flags when linking, use for AArch64 BTI/PAC-RET

LTO objects might compiled with different `mbranch-protection` flags which will cause an error in the linker.
Such a setup is allowed in the normal build with this change that is possible.

Reviewed By: pcc

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

show more ...

[AutoUpgrade] Fix -Wunused-variable in -DLLVM_ENABLE_ASSERTIONS=off builds

[AutoUpgrade] Don't upgrade intrinsics returning overloaded struct type

We only want to do the upgrade from named to anonymous struct
return if the intrinsic is declared to return a struct, but not

[AutoUpgrade] Don't upgrade intrinsics returning overloaded struct type

We only want to do the upgrade from named to anonymous struct
return if the intrinsic is declared to return a struct, but not
if it has an overloaded return type that just happens to be a
struct. In that case the struct type will be mangled into the
intrinsic name and there is no problem.

This should address the problem reported in
https://reviews.llvm.org/D122471#3416598.

show more ...

[IR] Require intrinsic struct return type to be anonymous

This is an alternative to D122376. Rather than working around the
problem, this patch requires that struct return types in intrinsics
are an

[IR] Require intrinsic struct return type to be anonymous

This is an alternative to D122376. Rather than working around the
problem, this patch requires that struct return types in intrinsics
are anonymous/literal and adds auto-upgrade code to convert
existing uses of intrinsics with named struct types.

This ensures that the mapping between intrinsic name and
intrinsic function type is actually bijective, as it is supposed
to be.

This also fixes https://github.com/llvm/llvm-project/issues/37891.

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

show more ...

[Bitcode] Move x86_intrcc upgrade to bitcode reader

This upgrade requires access the legacy pointer element type, so
it needs to happen inside the bitcode reader.

[AutoUpgrade] Handle remangling upgrade for ptr.annotation

The code assumed that the upgrade would happen due to the argument
count changing from 4 to 5. However, a remangling upgrade is also
possib

[AutoUpgrade] Handle remangling upgrade for ptr.annotation

The code assumed that the upgrade would happen due to the argument
count changing from 4 to 5. However, a remangling upgrade is also
possible here.

show more ...

[AutoUpgrade] Also upgrade intrinsics in invokes

We currently don't have any specialized upgrades for intrinsics
that can be used in invokes, but they can still be subject to
a generic remangling up

[AutoUpgrade] Also upgrade intrinsics in invokes

We currently don't have any specialized upgrades for intrinsics
that can be used in invokes, but they can still be subject to
a generic remangling upgrade. In particular, this happens when
upgrading statepoint intrinsics under -opaque-pointers.

This patch just changes the upgrade code to work on CallBase
instead of CallInst in particular.

show more ...

[llvm] Use = default (NFC)

Reduce dependencies on llvm/BinaryFormat/Dwarf.h

This header is very large (3M Lines once expended) and was included in location
where dwarf-specific information were not needed.

More specifically,

Reduce dependencies on llvm/BinaryFormat/Dwarf.h

This header is very large (3M Lines once expended) and was included in location
where dwarf-specific information were not needed.

More specifically, this commit suppresses the dependencies on
llvm/BinaryFormat/Dwarf.h in two headers: llvm/IR/IRBuilder.h and
llvm/IR/DebugInfoMetadata.h. As these headers (esp. the former) are widely used,
this has a decent impact on number of preprocessed lines generated during
compilation of LLVM, as showcased below.

This is achieved by moving some definitions back to the .cpp file, no
performance impact implied[0].

As a consequence of that patch, downstream user may need to manually some extra
files:

llvm/IR/IRBuilder.h no longer includes llvm/BinaryFormat/Dwarf.h
llvm/IR/DebugInfoMetadata.h no longer includes llvm/BinaryFormat/Dwarf.h

In some situations, codes maybe relying on the fact that
llvm/BinaryFormat/Dwarf.h was including llvm/ADT/Triple.h, this hidden
dependency now needs to be explicit.

$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Transforms/Scalar/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
after: 10978519
before: 11245451

Related Discourse thread: https://llvm.discourse.group/t/include-what-you-use-include-cleanup
[0] https://llvm-compile-time-tracker.com/compare.php?from=fa7145dfbf94cb93b1c3e610582c495cb806569b&to=995d3e326ee1d9489145e20762c65465a9caeab4&stat=instructions

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

show more ...

Cleanup header dependencies in LLVMCore

Based on the output of include-what-you-use.

This is a big chunk of changes. It is very likely to break downstream code
unless they took a lot of care in avo

Cleanup header dependencies in LLVMCore

Based on the output of include-what-you-use.

This is a big chunk of changes. It is very likely to break downstream code
unless they took a lot of care in avoiding hidden ehader dependencies, something
the LLVM codebase doesn't do that well :-/

I've tried to summarize the biggest change below:

- llvm/include/llvm-c/Core.h: no longer includes llvm-c/ErrorHandling.h
- llvm/IR/DIBuilder.h no longer includes llvm/IR/DebugInfo.h
- llvm/IR/IRBuilder.h no longer includes llvm/IR/IntrinsicInst.h
- llvm/IR/LLVMRemarkStreamer.h no longer includes llvm/Support/ToolOutputFile.h
- llvm/IR/LegacyPassManager.h no longer include llvm/Pass.h
- llvm/IR/Type.h no longer includes llvm/ADT/SmallPtrSet.h
- llvm/IR/PassManager.h no longer includes llvm/Pass.h nor llvm/Support/Debug.h

And the usual count of preprocessed lines:
$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/IR/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 6400831
after: 6189948

200k lines less to process is no that bad ;-)

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup

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

show more ...

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecatin

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecating the API.

show more ...

[X86][MS] Change the alignment of f80 to 16 bytes on Windows 32bits to match with ICC

MSVC currently doesn't support 80 bits long double. ICC supports it when
the option `/Qlong-double` is specified

[X86][MS] Change the alignment of f80 to 16 bytes on Windows 32bits to match with ICC

MSVC currently doesn't support 80 bits long double. ICC supports it when
the option `/Qlong-double` is specified. Changing the alignment of f80
to 16 bytes so that we can be compatible with ICC's option.

Reviewed By: rnk, craig.topper

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

show more ...

AMDGPU: Remove llvm.amdgcn.alignbit and handle bitcode upgrade to fshr

[AttrBuilder] Add string attribute getter (NFC)

This avoids the need to scan through td_attrs() in AutoUpgrade,
decoupling it from AttrBuilder implementation details.

Revert "[X86][MS] Change the alignment of f80 to 16 bytes on Windows 32bits to match with ICC"

This reverts commit 1bb0caf561688681be67cc91560348c9e43fcbf3.

[X86][MS] Change the alignment of f80 to 16 bytes on Windows 32bits to match with ICC

MSVC currently doesn't support 80 bits long double. ICC supports it when
the option `/Qlong-double` is specified

[X86][MS] Change the alignment of f80 to 16 bytes on Windows 32bits to match with ICC

MSVC currently doesn't support 80 bits long double. ICC supports it when
the option `/Qlong-double` is specified. Changing the alignment of f80
to 16 bytes so that we can be compatible with ICC's option.

Reviewed By: rnk, craig.topper

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

show more ...

Use a sorted array instead of a map to store AttrBuilder string attributes

Using and std::map<SmallString, SmallString> for target dependent attributes is
inefficient: it makes its constructor sligh

Use a sorted array instead of a map to store AttrBuilder string attributes

Using and std::map<SmallString, SmallString> for target dependent attributes is
inefficient: it makes its constructor slightly heavier, and involves extra
allocation for each new string attribute. Storing the attribute key/value as
strings implies extra allocation/copy step.

Use a sorted vector instead. Given the low number of attributes generally
involved, this is cheaper, as showcased by

https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions

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

show more ...

[IR][AutoUpgrade] Merge x86 mask load intrinsic upgrades. NFC.

Helps appease MSVC which is complaining about "fatal error C1061: compiler limit: blocks nested too deeply" - we already do the same th

[IR][AutoUpgrade] Merge x86 mask load intrinsic upgrades. NFC.

Helps appease MSVC which is complaining about "fatal error C1061: compiler limit: blocks nested too deeply" - we already do the same thing for avx512.mask.store intrinsics.

This is only a stopgap solution until another else-if case needs adding - we really need to refactor this chain of ifs properly.

show more ...

[ARM] Separate ARM autoupgrade code into a separate function

Try to appease the microsoft compiler which is apparently running out of
if statements. Separate the new ARM code into a separate functio

[ARM] Separate ARM autoupgrade code into a separate function

Try to appease the microsoft compiler which is apparently running out of
if statements. Separate the new ARM code into a separate function to
keep it simpler.

show more ...