[CodeGen] Remove some implict conversions of MCRegister to unsigned by using(). NFC

Many of these are indexing BitVectors or something where we can't
using MCRegister and need the register number.

Revert "[ARM] musttail fixes"
committed by accident, see #104795

This reverts commit a2088a24dad31ebe44c93751db17307fdbe1f0e2.

Revert "Seperate frontend changes, add debug directives, remove redundant stuff from tests"

This reverts commit 1a908c6be3317bbbac73e6a6fc52cabefbdebf7d.

Seperate frontend changes, add debug directives, remove redundant stuff from tests

[ARM] musttail fixes

Backend:
- Caller and callee arguments no longer have to match, just to take up the same space, as they can be changed before the call
- Allowed tail calls if callee and callee

[ARM] musttail fixes

Backend:
- Caller and callee arguments no longer have to match, just to take up the same space, as they can be changed before the call
- Allowed tail calls if callee and callee both (or neither) use sret, wheras before it would be dissalowed if either used sret
- Allowed tail calls if byval args are used
- Added debug trace for IsEligibleForTailCallOptimisation

Frontend (clang):
- Do not generate extra alloca if sret is used with musttail, as the space for the sret is allocated already

Change-Id: Ic7f246a7eca43c06874922d642d7dc44bdfc98ec

show more ...

[CodeGen] Support allocating of arguments by decreasing offsets

Previously, `CCState::AllocateStack` always allocated stack space by increasing
offsets. For targets with stack growing up (away from

[CodeGen] Support allocating of arguments by decreasing offsets

Previously, `CCState::AllocateStack` always allocated stack space by increasing
offsets. For targets with stack growing up (away from zero) it is more
convenient to allocate arguments by decreasing offsets, so that the first
argument is at the top of the stack. This is important when calling a function
with variable number of arguments: the callee does not know the size of the
stack, but must be able to access "fixed" arguments. For that to work, the
"fixed" arguments should have fixed offsets relative to the stack top, i.e. the
variadic arguments area should be at the stack bottom (at lowest addresses).

The in-tree target with stack growing up is AMDGPU, but it allocates
arguments by increasing addresses. It does not support variadic arguments.

A drive-by change is to promote stack size/offset to 64-bit integer.
This is what MachineFrameInfo expects.

Reviewed By: arsenm

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

show more ...

[CodeGen] Replace CCState's getNextStackOffset with getStackSize (NFC)

The term "next stack offset" is misleading because the next argument is
not necessarily allocated at this offset due to alignme

[CodeGen] Replace CCState's getNextStackOffset with getStackSize (NFC)

The term "next stack offset" is misleading because the next argument is
not necessarily allocated at this offset due to alignment constrains.
It also does not make much sense when allocating arguments at negative
offsets (introduced in a follow-up patch), because the returned offset
would be past the end of the next argument.

Reviewed By: arsenm

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

show more ...

[CodeGen] Add standard print/debug utilities to MVT

Doing so makes it easier to do printf style debugging in idiomatic manner. I followed the code structure of Value with only the definition of dump

[CodeGen] Add standard print/debug utilities to MVT

Doing so makes it easier to do printf style debugging in idiomatic manner. I followed the code structure of Value with only the definition of dump being #ifdef out in non-debug builds. Not sure if this is the "right" option; we don't seem to have any single consistent scheme on how dump is handled.

Note: This is a follow up to D143454 which did the same for EVT.

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

show more ...

[CodeGen] Replace CCValAssign::Loc with std::variant (NFCI)

The motivation behind this change is as follows.
Targets with stack growing up (there are no such in-tree targets) pass
arguments at negat

[CodeGen] Replace CCValAssign::Loc with std::variant (NFCI)

The motivation behind this change is as follows.
Targets with stack growing up (there are no such in-tree targets) pass
arguments at negative offsets relative to the stack pointer. This makes
it hard to use the generic value assigner because CCValAssign stores the
offset as an unsigned integer, which is then zero-extended when
converted to int64_t, e.g. when passing to `CreateFixedObject`. This
results in conversion of, for example, -4 into 4294967292, which is not
desired.

While it is possible to insert a cast to `int` before passing the result
of `getLocMemOffset` into `CreateFixedObject` in backend code, this is
error-prone, and some uses of `getLocMemOffset` are located in
places common to all backends (e.g. `CallLowering::handleAssignments`).

That said, I wanted to change the type of the memory offset from
`unsigned` to `int64_t` (this would be consistent with other places
where stack offsets are used). However, the `Loc` field which stores the
offset is shared between three different kinds of the location:
register, memory, and "pending". Storing a register number as `int64_t`
does not seem right (there are `Register` and `MCRegister` for this), so
I did the most straightforward change - replaced the `Loc` field with
std::variant.

The main change that changes the type of the memory offset from
`unsigned` to `int64_t` will be in a follow-up patch to simplify the
review.

Reviewed By: MaskRay, nikic

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

show more ...

Use CTAD on llvm::SaveAndRestore

Reviewed By: dblaikie

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

Cleanup includes: final pass

Cleanup a few extra files, this closes the work on libLLVM dependencies on my
side.

Impact on libLLVM preprocessed output: -35876 lines

Discourse thread: https://disco

Cleanup includes: final pass

Cleanup a few extra files, this closes the work on libLLVM dependencies on my
side.

Impact on libLLVM preprocessed output: -35876 lines

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D122576

show more ...

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-in

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121681

show more ...

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https:/

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https://reviews.llvm.org/D121169

show more ...

Cleanup codegen includes

after: 1061034926
before: 1063332844

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

Use RegisterInfo::regsOverlaps instead of checking aliases

This is both less code and faster since it doesn't have to expand all
the sub & superreg sets. NFCI.

[SVE] Deal with SVE tuple call arguments correctly when running out of registers

When passing SVE types as arguments to function calls we can run
out of hardware SVE registers. This is normally fine

[SVE] Deal with SVE tuple call arguments correctly when running out of registers

When passing SVE types as arguments to function calls we can run
out of hardware SVE registers. This is normally fine, since we
switch to an indirect mode where we pass a pointer to a SVE stack
object in a GPR. However, if we switch over part-way through
processing a SVE tuple then part of it will be in registers and
the other part will be on the stack.

I've fixed this by ensuring that:

1. When we don't have enough registers to allocate the whole block
we mark any remaining SVE registers temporarily as allocated.
2. We temporarily remove the InConsecutiveRegs flags from the last
tuple part argument and reinvoke the autogenerated calling
convention handler. Doing this prevents the code from entering
an infinite recursion and, in combination with 1), ensures we
switch over to the Indirect mode.
3. After allocating a GPR register for the pointer to the tuple we
then deallocate any SVE registers we marked as allocated in 1).
We also set the InConsecutiveRegs flags back how they were before.
4. I've changed the AArch64ISelLowering LowerCALL and
LowerFormalArguments functions to detect the start of a tuple,
which involves allocating a single stack object and doing the
correct numbers of legal loads and stores.

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

show more ...

Cleanup CodeGen/CallingConvLower.cpp

Patch by pi1024e (email unavailable)

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

CallingConvLower.h - remove unnecessary MachineFunction.h include. NFC.

Reduce to forward declaration, add the Register.h include that we still needed, move CCState::ensureMaxAlignment into CallingC

CallingConvLower.h - remove unnecessary MachineFunction.h include. NFC.

Reduce to forward declaration, add the Register.h include that we still needed, move CCState::ensureMaxAlignment into CallingConvLower.cpp as it was the only function that needed the full definition of MachineFunction.

Fix a few implicit dependencies further down.

show more ...

[Alignment][NFC] Deprecate dead code from CallingConvLower.h

Summary: This is a followup on D81196.

Reviewers: courbet

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: htt

[Alignment][NFC] Deprecate dead code from CallingConvLower.h

Summary: This is a followup on D81196.

Reviewers: courbet

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

show more ...

[Alignment][NFC] Migrate HandleByVal to Align

Summary: Note to downstream target maintainers: this might silently change the semantics of your code if you override `TargetLowering::HandleByVal` with

[Alignment][NFC] Migrate HandleByVal to Align

Summary: Note to downstream target maintainers: this might silently change the semantics of your code if you override `TargetLowering::HandleByVal` without marking it `override`.

This patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: sdardis, hiraditya, jrtc27, atanasyan, llvm-commits

Tags: #llvm

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

show more ...

Reland "[CodeGen] Make logic of CCState::resultsCompatible clearer"

This relands commit d782d1f898eaafee49548d5332e84c3ae11ebac4.
With a typo fixed, which was causing the x86 test failure.

Revert "[CodeGen] Make logic of CCState::resultsCompatible clearer"

This reverts commit d782d1f898eaafee49548d5332e84c3ae11ebac4
which caused test CodeGen/X86/sibcall.ll to fail.

[CodeGen] Make logic of CCState::resultsCompatible clearer

CodeGen: Use Register more in CallLowering

Some of these MCPhysReg uses should probably be MCRegister, but right
now this would require more invasive changes.

[Alignment][NFC] Use Align for getMemcpy/Memmove/Memset

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-d

[Alignment][NFC] Use Align for getMemcpy/Memmove/Memset

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: arsenm, dschuff, jyknight, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, kerbowa, llvm-commits

Tags: #llvm

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

show more ...