Many of these are indexing BitVectors or something where we can't using MCRegister and need the register number.
committed by accident, see #104795 This reverts commit a2088a24dad31ebe44c93751db17307fdbe1f0e2.
This reverts commit 1a908c6be3317bbbac73e6a6fc52cabefbdebf7d.
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
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
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
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
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