2009-11-23 18:16:22 +01:00
|
|
|
//===-- FunctionLoweringInfo.cpp ------------------------------------------===//
|
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2009-11-23 18:16:22 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This implements routines for translating functions from LLVM IR into
|
|
|
|
// Machine IR.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2010-07-07 18:01:37 +02:00
|
|
|
#include "llvm/CodeGen/FunctionLoweringInfo.h"
|
2020-05-25 13:56:44 +02:00
|
|
|
#include "llvm/ADT/APInt.h"
|
2019-10-19 03:31:09 +02:00
|
|
|
#include "llvm/Analysis/LegacyDivergenceAnalysis.h"
|
2012-12-03 17:50:05 +01:00
|
|
|
#include "llvm/CodeGen/Analysis.h"
|
|
|
|
#include "llvm/CodeGen/MachineFrameInfo.h"
|
|
|
|
#include "llvm/CodeGen/MachineFunction.h"
|
|
|
|
#include "llvm/CodeGen/MachineInstrBuilder.h"
|
|
|
|
#include "llvm/CodeGen/MachineRegisterInfo.h"
|
2017-11-08 02:01:31 +01:00
|
|
|
#include "llvm/CodeGen/TargetFrameLowering.h"
|
|
|
|
#include "llvm/CodeGen/TargetInstrInfo.h"
|
2017-11-17 02:07:10 +01:00
|
|
|
#include "llvm/CodeGen/TargetLowering.h"
|
|
|
|
#include "llvm/CodeGen/TargetRegisterInfo.h"
|
|
|
|
#include "llvm/CodeGen/TargetSubtargetInfo.h"
|
2018-06-19 02:26:39 +02:00
|
|
|
#include "llvm/CodeGen/WasmEHFuncInfo.h"
|
2015-03-31 00:58:10 +02:00
|
|
|
#include "llvm/CodeGen/WinEHFuncInfo.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
|
|
|
#include "llvm/IR/LLVMContext.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
2009-11-23 18:16:22 +01:00
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
|
|
|
#include "llvm/Support/MathExtras.h"
|
2015-03-23 20:32:43 +01:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2012-12-03 17:50:05 +01:00
|
|
|
#include "llvm/Target/TargetOptions.h"
|
2009-11-23 18:16:22 +01:00
|
|
|
#include <algorithm>
|
|
|
|
using namespace llvm;
|
|
|
|
|
2014-04-22 04:02:50 +02:00
|
|
|
#define DEBUG_TYPE "function-lowering-info"
|
|
|
|
|
2009-11-23 18:16:22 +01:00
|
|
|
/// isUsedOutsideOfDefiningBlock - Return true if this instruction is used by
|
|
|
|
/// PHI nodes or outside of the basic block that defines it, or used by a
|
|
|
|
/// switch or atomic instruction, which may expand to multiple basic blocks.
|
2010-04-15 06:33:49 +02:00
|
|
|
static bool isUsedOutsideOfDefiningBlock(const Instruction *I) {
|
2010-04-20 16:50:13 +02:00
|
|
|
if (I->use_empty()) return false;
|
2009-11-23 18:16:22 +01:00
|
|
|
if (isa<PHINode>(I)) return true;
|
2010-04-15 06:33:49 +02:00
|
|
|
const BasicBlock *BB = I->getParent();
|
2014-03-09 04:16:01 +01:00
|
|
|
for (const User *U : I->users())
|
2010-07-09 18:08:33 +02:00
|
|
|
if (cast<Instruction>(U)->getParent() != BB || isa<PHINode>(U))
|
2009-11-23 18:16:22 +01:00
|
|
|
return true;
|
2014-03-09 04:16:01 +01:00
|
|
|
|
2009-11-23 18:16:22 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-09-19 07:30:35 +02:00
|
|
|
static ISD::NodeType getPreferredExtendForValue(const Value *V) {
|
|
|
|
// For the users of the source value being used for compare instruction, if
|
|
|
|
// the number of signed predicate is greater than unsigned predicate, we
|
|
|
|
// prefer to use SIGN_EXTEND.
|
|
|
|
//
|
|
|
|
// With this optimization, we would be able to reduce some redundant sign or
|
|
|
|
// zero extension instruction, and eventually more machine CSE opportunities
|
|
|
|
// can be exposed.
|
|
|
|
ISD::NodeType ExtendKind = ISD::ANY_EXTEND;
|
|
|
|
unsigned NumOfSigned = 0, NumOfUnsigned = 0;
|
|
|
|
for (const User *U : V->users()) {
|
|
|
|
if (const auto *CI = dyn_cast<CmpInst>(U)) {
|
|
|
|
NumOfSigned += CI->isSigned();
|
|
|
|
NumOfUnsigned += CI->isUnsigned();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (NumOfSigned > NumOfUnsigned)
|
|
|
|
ExtendKind = ISD::SIGN_EXTEND;
|
|
|
|
|
|
|
|
return ExtendKind;
|
|
|
|
}
|
|
|
|
|
2014-03-05 03:43:26 +01:00
|
|
|
void FunctionLoweringInfo::set(const Function &fn, MachineFunction &mf,
|
|
|
|
SelectionDAG *DAG) {
|
2009-11-23 18:16:22 +01:00
|
|
|
Fn = &fn;
|
|
|
|
MF = &mf;
|
2014-10-09 02:57:31 +02:00
|
|
|
TLI = MF->getSubtarget().getTargetLowering();
|
2009-11-23 18:16:22 +01:00
|
|
|
RegInfo = &MF->getRegInfo();
|
2015-11-28 12:02:32 +01:00
|
|
|
const TargetFrameLowering *TFI = MF->getSubtarget().getFrameLowering();
|
2019-05-26 22:33:26 +02:00
|
|
|
DA = DAG->getDivergenceAnalysis();
|
2009-11-23 18:16:22 +01:00
|
|
|
|
2010-07-10 11:00:22 +02:00
|
|
|
// Check whether the function can return without sret-demotion.
|
|
|
|
SmallVector<ISD::OutputArg, 4> Outs;
|
2018-07-28 15:25:19 +02:00
|
|
|
CallingConv::ID CC = Fn->getCallingConv();
|
|
|
|
|
|
|
|
GetReturnInfo(CC, Fn->getReturnType(), Fn->getAttributes(), Outs, *TLI,
|
2015-07-09 03:57:34 +02:00
|
|
|
mf.getDataLayout());
|
2018-07-28 15:25:19 +02:00
|
|
|
CanLowerReturn =
|
|
|
|
TLI->CanLowerReturn(CC, *MF, Fn->isVarArg(), Outs, Fn->getContext());
|
2010-07-10 11:00:22 +02:00
|
|
|
|
2016-03-03 01:01:25 +01:00
|
|
|
// If this personality uses funclets, we need to do a bit more work.
|
2016-10-19 19:08:23 +02:00
|
|
|
DenseMap<const AllocaInst *, TinyPtrVector<int *>> CatchObjects;
|
2016-03-03 01:01:25 +01:00
|
|
|
EHPersonality Personality = classifyEHPersonality(
|
|
|
|
Fn->hasPersonalityFn() ? Fn->getPersonalityFn() : nullptr);
|
|
|
|
if (isFuncletEHPersonality(Personality)) {
|
|
|
|
// Calculate state numbers if we haven't already.
|
|
|
|
WinEHFuncInfo &EHInfo = *MF->getWinEHFuncInfo();
|
|
|
|
if (Personality == EHPersonality::MSVC_CXX)
|
|
|
|
calculateWinCXXEHStateNumbers(&fn, EHInfo);
|
|
|
|
else if (isAsynchronousEHPersonality(Personality))
|
|
|
|
calculateSEHStateNumbers(&fn, EHInfo);
|
|
|
|
else if (Personality == EHPersonality::CoreCLR)
|
|
|
|
calculateClrEHStateNumbers(&fn, EHInfo);
|
|
|
|
|
|
|
|
// Map all BB references in the WinEH data to MBBs.
|
|
|
|
for (WinEHTryBlockMapEntry &TBME : EHInfo.TryBlockMap) {
|
|
|
|
for (WinEHHandlerType &H : TBME.HandlerArray) {
|
|
|
|
if (const AllocaInst *AI = H.CatchObj.Alloca)
|
2016-10-19 19:08:23 +02:00
|
|
|
CatchObjects.insert({AI, {}}).first->second.push_back(
|
|
|
|
&H.CatchObj.FrameIndex);
|
2016-03-03 01:01:25 +01:00
|
|
|
else
|
|
|
|
H.CatchObj.FrameIndex = INT_MAX;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2018-06-19 02:26:39 +02:00
|
|
|
if (Personality == EHPersonality::Wasm_CXX) {
|
|
|
|
WasmEHFuncInfo &EHInfo = *MF->getWasmEHFuncInfo();
|
|
|
|
calculateWasmEHInfo(&fn, EHInfo);
|
|
|
|
}
|
2016-03-03 01:01:25 +01:00
|
|
|
|
2009-11-23 18:16:22 +01:00
|
|
|
// Initialize the mapping of values to registers. This is only set up for
|
|
|
|
// instruction values that are used outside of the block that defines
|
|
|
|
// them.
|
[Alignment][NFC] Use TFL::getStackAlign()
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: dylanmckay, sdardis, nemanjai, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76551
2020-03-21 21:41:33 +01:00
|
|
|
const Align StackAlign = TFI->getStackAlign();
|
2016-12-30 01:21:38 +01:00
|
|
|
for (const BasicBlock &BB : *Fn) {
|
|
|
|
for (const Instruction &I : BB) {
|
|
|
|
if (const AllocaInst *AI = dyn_cast<AllocaInst>(&I)) {
|
2015-11-28 12:02:32 +01:00
|
|
|
Type *Ty = AI->getAllocatedType();
|
2020-05-06 21:06:29 +02:00
|
|
|
Align TyPrefAlign = MF->getDataLayout().getPrefTypeAlign(Ty);
|
|
|
|
// The "specified" alignment is the alignment written on the alloca,
|
|
|
|
// or the preferred alignment of the type if none is specified.
|
|
|
|
//
|
|
|
|
// (Unspecified alignment on allocas will be going away soon.)
|
2020-05-15 22:23:14 +02:00
|
|
|
Align SpecifiedAlign = AI->getAlign();
|
2020-05-06 21:06:29 +02:00
|
|
|
|
|
|
|
// If the preferred alignment of the type is higher than the specified
|
|
|
|
// alignment of the alloca, promote the alignment, as long as it doesn't
|
|
|
|
// require realigning the stack.
|
|
|
|
//
|
|
|
|
// FIXME: Do we really want to second-guess the IR in isel?
|
[Alignment][NFC] Use TFL::getStackAlign()
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: dylanmckay, sdardis, nemanjai, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76551
2020-03-21 21:41:33 +01:00
|
|
|
Align Alignment =
|
2020-05-06 21:06:29 +02:00
|
|
|
std::max(std::min(TyPrefAlign, StackAlign), SpecifiedAlign);
|
2015-11-28 12:02:32 +01:00
|
|
|
|
|
|
|
// Static allocas can be folded into the initial stack frame
|
|
|
|
// adjustment. For targets that don't realign the stack, don't
|
|
|
|
// do this if there is an extra alignment requirement.
|
2016-12-30 01:21:38 +01:00
|
|
|
if (AI->isStaticAlloca() &&
|
[Alignment][NFC] Use TFL::getStackAlign()
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: dylanmckay, sdardis, nemanjai, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76551
2020-03-21 21:41:33 +01:00
|
|
|
(TFI->isStackRealignable() || (Alignment <= StackAlign))) {
|
2014-09-02 20:42:44 +02:00
|
|
|
const ConstantInt *CUI = cast<ConstantInt>(AI->getArraySize());
|
2019-11-13 09:31:49 +01:00
|
|
|
uint64_t TySize =
|
|
|
|
MF->getDataLayout().getTypeAllocSize(Ty).getKnownMinSize();
|
2014-09-02 20:42:44 +02:00
|
|
|
|
|
|
|
TySize *= CUI->getZExtValue(); // Get total allocated size.
|
|
|
|
if (TySize == 0) TySize = 1; // Don't create zero-sized stack objects.
|
2016-03-03 01:01:25 +01:00
|
|
|
int FrameIndex = INT_MAX;
|
|
|
|
auto Iter = CatchObjects.find(AI);
|
|
|
|
if (Iter != CatchObjects.end() && TLI->needsFixedCatchObjects()) {
|
2016-07-28 20:40:00 +02:00
|
|
|
FrameIndex = MF->getFrameInfo().CreateFixedObject(
|
2019-07-16 06:46:31 +02:00
|
|
|
TySize, 0, /*IsImmutable=*/false, /*isAliased=*/true);
|
[Alignment][NFC] Use TFL::getStackAlign()
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: dylanmckay, sdardis, nemanjai, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76551
2020-03-21 21:41:33 +01:00
|
|
|
MF->getFrameInfo().setObjectAlignment(FrameIndex, Alignment);
|
2016-03-03 01:01:25 +01:00
|
|
|
} else {
|
[Alignment][NFC] Use TFL::getStackAlign()
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: dylanmckay, sdardis, nemanjai, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76551
2020-03-21 21:41:33 +01:00
|
|
|
FrameIndex = MF->getFrameInfo().CreateStackObject(TySize, Alignment,
|
|
|
|
false, AI);
|
2016-03-03 01:01:25 +01:00
|
|
|
}
|
2014-09-02 20:42:44 +02:00
|
|
|
|
2019-11-13 09:31:49 +01:00
|
|
|
// Scalable vectors may need a special StackID to distinguish
|
|
|
|
// them from other (fixed size) stack objects.
|
2020-04-23 21:45:34 +02:00
|
|
|
if (isa<ScalableVectorType>(Ty))
|
2019-11-13 09:31:49 +01:00
|
|
|
MF->getFrameInfo().setStackID(FrameIndex,
|
|
|
|
TFI->getStackIDForScalableVectors());
|
|
|
|
|
2016-03-03 01:01:25 +01:00
|
|
|
StaticAllocaMap[AI] = FrameIndex;
|
|
|
|
// Update the catch handler information.
|
2016-10-19 19:08:23 +02:00
|
|
|
if (Iter != CatchObjects.end()) {
|
|
|
|
for (int *CatchObjPtr : Iter->second)
|
|
|
|
*CatchObjPtr = FrameIndex;
|
|
|
|
}
|
2014-09-02 20:42:44 +02:00
|
|
|
} else {
|
2015-11-28 12:02:32 +01:00
|
|
|
// FIXME: Overaligned static allocas should be grouped into
|
|
|
|
// a single dynamic allocation instead of using a separate
|
|
|
|
// stack allocation for each one.
|
2014-03-05 03:43:26 +01:00
|
|
|
// Inform the Frame Information that we have variable-sized objects.
|
[Alignment][NFC] Use TFL::getStackAlign()
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: dylanmckay, sdardis, nemanjai, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76551
2020-03-21 21:41:33 +01:00
|
|
|
MF->getFrameInfo().CreateVariableSizedObject(
|
2020-07-01 16:31:21 +02:00
|
|
|
Alignment <= StackAlign ? Align(1) : Alignment, AI);
|
2014-03-05 03:43:26 +01:00
|
|
|
}
|
2021-03-16 10:11:57 +01:00
|
|
|
} else if (auto *Call = dyn_cast<CallBase>(&I)) {
|
|
|
|
// Look for inline asm that clobbers the SP register.
|
2020-04-28 05:15:59 +02:00
|
|
|
if (Call->isInlineAsm()) {
|
2020-10-21 10:15:13 +02:00
|
|
|
Register SP = TLI->getStackPointerRegisterToSaveRestore();
|
2015-02-26 23:38:43 +01:00
|
|
|
const TargetRegisterInfo *TRI = MF->getSubtarget().getRegisterInfo();
|
2014-03-05 03:43:26 +01:00
|
|
|
std::vector<TargetLowering::AsmOperandInfo> Ops =
|
2020-04-12 06:45:09 +02:00
|
|
|
TLI->ParseConstraints(Fn->getParent()->getDataLayout(), TRI,
|
|
|
|
*Call);
|
2016-12-30 01:21:38 +01:00
|
|
|
for (TargetLowering::AsmOperandInfo &Op : Ops) {
|
2014-03-05 03:43:26 +01:00
|
|
|
if (Op.Type == InlineAsm::isClobber) {
|
|
|
|
// Clobbers don't have SDValue operands, hence SDValue().
|
|
|
|
TLI->ComputeConstraintToUse(Op, SDValue(), DAG);
|
2014-10-09 02:57:31 +02:00
|
|
|
std::pair<unsigned, const TargetRegisterClass *> PhysReg =
|
2015-02-26 23:38:43 +01:00
|
|
|
TLI->getRegForInlineAsmConstraint(TRI, Op.ConstraintCode,
|
|
|
|
Op.ConstraintVT);
|
2014-03-05 03:43:26 +01:00
|
|
|
if (PhysReg.first == SP)
|
2016-07-28 20:40:00 +02:00
|
|
|
MF->getFrameInfo().setHasOpaqueSPAdjustment(true);
|
2014-03-05 03:43:26 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2021-03-16 10:11:57 +01:00
|
|
|
// Look for calls to the @llvm.va_start intrinsic. We can omit some
|
|
|
|
// prologue boilerplate for variadic functions that don't examine their
|
|
|
|
// arguments.
|
|
|
|
if (const auto *II = dyn_cast<IntrinsicInst>(&I)) {
|
|
|
|
if (II->getIntrinsicID() == Intrinsic::vastart)
|
|
|
|
MF->getFrameInfo().setHasVAStart(true);
|
|
|
|
}
|
2014-08-22 23:59:26 +02:00
|
|
|
|
2021-03-16 10:11:57 +01:00
|
|
|
// If we have a musttail call in a variadic function, we need to ensure
|
|
|
|
// we forward implicit register parameters.
|
|
|
|
if (const auto *CI = dyn_cast<CallInst>(&I)) {
|
|
|
|
if (CI->isMustTailCall() && Fn->isVarArg())
|
|
|
|
MF->getFrameInfo().setHasMustTailInVarArgFunc(true);
|
|
|
|
}
|
2014-08-29 23:42:08 +02:00
|
|
|
}
|
|
|
|
|
2010-07-16 19:54:27 +02:00
|
|
|
// Mark values used outside their block as exported, by allocating
|
|
|
|
// a virtual register for them.
|
2016-12-30 01:21:38 +01:00
|
|
|
if (isUsedOutsideOfDefiningBlock(&I))
|
|
|
|
if (!isa<AllocaInst>(I) || !StaticAllocaMap.count(cast<AllocaInst>(&I)))
|
|
|
|
InitializeRegForValue(&I);
|
2009-11-23 18:16:22 +01:00
|
|
|
|
2014-09-19 07:30:35 +02:00
|
|
|
// Decide the preferred extend type for a value.
|
2016-12-30 01:21:38 +01:00
|
|
|
PreferredExtendType[&I] = getPreferredExtendForValue(&I);
|
2010-07-16 19:54:27 +02:00
|
|
|
}
|
2016-12-30 01:21:38 +01:00
|
|
|
}
|
2010-07-16 19:54:27 +02:00
|
|
|
|
2009-11-23 18:16:22 +01:00
|
|
|
// Create an initial MachineBasicBlock for each LLVM BasicBlock in F. This
|
|
|
|
// also creates the initial PHI MachineInstrs, though none of the input
|
|
|
|
// operands are populated.
|
2016-12-30 01:21:38 +01:00
|
|
|
for (const BasicBlock &BB : *Fn) {
|
2015-09-09 01:28:38 +02:00
|
|
|
// Don't create MachineBasicBlocks for imaginary EH pad blocks. These blocks
|
|
|
|
// are really data, and no instructions can live here.
|
2016-12-30 01:21:38 +01:00
|
|
|
if (BB.isEHPad()) {
|
|
|
|
const Instruction *PadInst = BB.getFirstNonPHI();
|
2015-11-05 22:09:49 +01:00
|
|
|
// If this is a non-landingpad EH pad, mark this function as using
|
2015-10-07 01:31:59 +02:00
|
|
|
// funclets.
|
[WebAssembly] Add functions for EHScopes
Summary:
There are functions using the term 'funclet' to refer to both
1. an EH scopes, the structure of BBs that starts with
catchpad/cleanuppad and ends with catchret/cleanupret, and
2. a small function that gets outlined in AsmPrinter, which is the
original meaning of 'funclet'.
So far the two have been the same thing; EH scopes are always outlined
in AsmPrinter as funclets at the end of the compilation pipeline. But
now wasm also uses scope-based EH but does not outline those, so we now
need to correctly distinguish those two use cases in functions.
This patch splits `MachineBasicBlock::isFuncletEntry` into
`isFuncletEntry` and `isEHScopeEntry`, and
`MachineFunction::hasFunclets` into `hasFunclets` and `hasEHScopes`, in
order to distinguish the two different use cases. And this also changes
some uses of the term 'funclet' to 'scope' in `getFuncletMembership` and
change the function name to `getEHScopeMembership` because this function
is not about outlined funclets but about EH scope memberships.
This change is in the same vein as D45559.
Reviewers: majnemer, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D47005
llvm-svn: 333045
2018-05-23 02:32:46 +02:00
|
|
|
// FIXME: SEH catchpads do not create EH scope/funclets, so we could avoid
|
|
|
|
// setting this in such cases in order to improve frame layout.
|
2016-12-30 01:21:38 +01:00
|
|
|
if (!isa<LandingPadInst>(PadInst)) {
|
[WebAssembly] Add functions for EHScopes
Summary:
There are functions using the term 'funclet' to refer to both
1. an EH scopes, the structure of BBs that starts with
catchpad/cleanuppad and ends with catchret/cleanupret, and
2. a small function that gets outlined in AsmPrinter, which is the
original meaning of 'funclet'.
So far the two have been the same thing; EH scopes are always outlined
in AsmPrinter as funclets at the end of the compilation pipeline. But
now wasm also uses scope-based EH but does not outline those, so we now
need to correctly distinguish those two use cases in functions.
This patch splits `MachineBasicBlock::isFuncletEntry` into
`isFuncletEntry` and `isEHScopeEntry`, and
`MachineFunction::hasFunclets` into `hasFunclets` and `hasEHScopes`, in
order to distinguish the two different use cases. And this also changes
some uses of the term 'funclet' to 'scope' in `getFuncletMembership` and
change the function name to `getEHScopeMembership` because this function
is not about outlined funclets but about EH scope memberships.
This change is in the same vein as D45559.
Reviewers: majnemer, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D47005
llvm-svn: 333045
2018-05-23 02:32:46 +02:00
|
|
|
MF->setHasEHScopes(true);
|
2016-12-01 20:32:15 +01:00
|
|
|
MF->setHasEHFunclets(true);
|
2016-07-28 20:40:00 +02:00
|
|
|
MF->getFrameInfo().setHasOpaqueSPAdjustment(true);
|
2015-11-05 22:09:49 +01:00
|
|
|
}
|
2016-12-30 01:21:38 +01:00
|
|
|
if (isa<CatchSwitchInst>(PadInst)) {
|
|
|
|
assert(&*BB.begin() == PadInst &&
|
2015-09-09 01:28:38 +02:00
|
|
|
"WinEHPrepare failed to remove PHIs from imaginary BBs");
|
|
|
|
continue;
|
|
|
|
}
|
2016-12-30 01:21:38 +01:00
|
|
|
if (isa<FuncletPadInst>(PadInst))
|
|
|
|
assert(&*BB.begin() == PadInst && "WinEHPrepare failed to demote PHIs");
|
2015-09-09 01:28:38 +02:00
|
|
|
}
|
|
|
|
|
2016-12-30 01:21:38 +01:00
|
|
|
MachineBasicBlock *MBB = mf.CreateMachineBasicBlock(&BB);
|
|
|
|
MBBMap[&BB] = MBB;
|
2009-11-23 18:16:22 +01:00
|
|
|
MF->push_back(MBB);
|
|
|
|
|
|
|
|
// Transfer the address-taken flag. This is necessary because there could
|
|
|
|
// be multiple MachineBasicBlocks corresponding to one BasicBlock, and only
|
|
|
|
// the first one should be marked.
|
2016-12-30 01:21:38 +01:00
|
|
|
if (BB.hasAddressTaken())
|
2009-11-23 18:16:22 +01:00
|
|
|
MBB->setHasAddressTaken();
|
|
|
|
|
2016-12-30 01:21:38 +01:00
|
|
|
// Mark landing pad blocks.
|
|
|
|
if (BB.isEHPad())
|
|
|
|
MBB->setIsEHPad();
|
|
|
|
|
2009-11-23 18:16:22 +01:00
|
|
|
// Create Machine PHI nodes for LLVM PHI nodes, lowering them as
|
|
|
|
// appropriate.
|
2017-12-30 16:27:33 +01:00
|
|
|
for (const PHINode &PN : BB.phis()) {
|
|
|
|
if (PN.use_empty())
|
|
|
|
continue;
|
2009-11-23 18:16:22 +01:00
|
|
|
|
2011-05-13 17:18:06 +02:00
|
|
|
// Skip empty types
|
2017-12-30 16:27:33 +01:00
|
|
|
if (PN.getType()->isEmptyTy())
|
2011-05-13 17:18:06 +02:00
|
|
|
continue;
|
|
|
|
|
2017-12-30 16:27:33 +01:00
|
|
|
DebugLoc DL = PN.getDebugLoc();
|
|
|
|
unsigned PHIReg = ValueMap[&PN];
|
2009-11-23 18:16:22 +01:00
|
|
|
assert(PHIReg && "PHI node does not have an assigned virtual register!");
|
|
|
|
|
|
|
|
SmallVector<EVT, 4> ValueVTs;
|
2017-12-30 16:27:33 +01:00
|
|
|
ComputeValueVTs(*TLI, MF->getDataLayout(), PN.getType(), ValueVTs);
|
2016-12-30 01:21:38 +01:00
|
|
|
for (EVT VT : ValueVTs) {
|
2013-06-06 02:11:39 +02:00
|
|
|
unsigned NumRegisters = TLI->getNumRegisters(Fn->getContext(), VT);
|
2014-08-05 04:39:49 +02:00
|
|
|
const TargetInstrInfo *TII = MF->getSubtarget().getInstrInfo();
|
2009-11-23 18:16:22 +01:00
|
|
|
for (unsigned i = 0; i != NumRegisters; ++i)
|
2010-02-09 20:54:29 +01:00
|
|
|
BuildMI(MBB, DL, TII->get(TargetOpcode::PHI), PHIReg + i);
|
2009-11-23 18:16:22 +01:00
|
|
|
PHIReg += NumRegisters;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2010-04-14 18:32:56 +02:00
|
|
|
|
2018-06-19 02:26:39 +02:00
|
|
|
if (isFuncletEHPersonality(Personality)) {
|
|
|
|
WinEHFuncInfo &EHInfo = *MF->getWinEHFuncInfo();
|
2015-09-10 02:25:23 +02:00
|
|
|
|
2018-06-19 02:26:39 +02:00
|
|
|
// Map all BB references in the WinEH data to MBBs.
|
|
|
|
for (WinEHTryBlockMapEntry &TBME : EHInfo.TryBlockMap) {
|
|
|
|
for (WinEHHandlerType &H : TBME.HandlerArray) {
|
|
|
|
if (H.Handler)
|
|
|
|
H.Handler = MBBMap[H.Handler.get<const BasicBlock *>()];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
for (CxxUnwindMapEntry &UME : EHInfo.CxxUnwindMap)
|
|
|
|
if (UME.Cleanup)
|
|
|
|
UME.Cleanup = MBBMap[UME.Cleanup.get<const BasicBlock *>()];
|
|
|
|
for (SEHUnwindMapEntry &UME : EHInfo.SEHUnwindMap) {
|
|
|
|
const auto *BB = UME.Handler.get<const BasicBlock *>();
|
|
|
|
UME.Handler = MBBMap[BB];
|
|
|
|
}
|
|
|
|
for (ClrEHUnwindMapEntry &CME : EHInfo.ClrEHUnwindMap) {
|
|
|
|
const auto *BB = CME.Handler.get<const BasicBlock *>();
|
|
|
|
CME.Handler = MBBMap[BB];
|
2015-09-16 22:16:27 +02:00
|
|
|
}
|
|
|
|
}
|
2018-06-19 02:26:39 +02:00
|
|
|
|
|
|
|
else if (Personality == EHPersonality::Wasm_CXX) {
|
|
|
|
WasmEHFuncInfo &EHInfo = *MF->getWasmEHFuncInfo();
|
2021-02-26 21:23:24 +01:00
|
|
|
// Map all BB references in the Wasm EH data to MBBs.
|
|
|
|
DenseMap<BBOrMBB, BBOrMBB> SrcToUnwindDest;
|
2021-02-21 19:10:47 +01:00
|
|
|
for (auto &KV : EHInfo.SrcToUnwindDest) {
|
2018-06-19 02:26:39 +02:00
|
|
|
const auto *Src = KV.first.get<const BasicBlock *>();
|
2021-02-26 21:23:24 +01:00
|
|
|
const auto *Dest = KV.second.get<const BasicBlock *>();
|
|
|
|
SrcToUnwindDest[MBBMap[Src]] = MBBMap[Dest];
|
2018-06-19 02:26:39 +02:00
|
|
|
}
|
2021-02-26 21:23:24 +01:00
|
|
|
EHInfo.SrcToUnwindDest = std::move(SrcToUnwindDest);
|
|
|
|
DenseMap<BBOrMBB, SmallPtrSet<BBOrMBB, 4>> UnwindDestToSrcs;
|
|
|
|
for (auto &KV : EHInfo.UnwindDestToSrcs) {
|
|
|
|
const auto *Dest = KV.first.get<const BasicBlock *>();
|
|
|
|
UnwindDestToSrcs[MBBMap[Dest]] = SmallPtrSet<BBOrMBB, 4>();
|
2021-03-10 19:36:59 +01:00
|
|
|
for (const auto P : KV.second)
|
2021-02-26 21:23:24 +01:00
|
|
|
UnwindDestToSrcs[MBBMap[Dest]].insert(
|
|
|
|
MBBMap[P.get<const BasicBlock *>()]);
|
[WebAssembly] Fix incorrect grouping and sorting of exceptions
This CL is not big but contains changes that span multiple analyses and
passes. This description is very long because it tries to explain basics
on what each pass/analysis does and why we need this change on top of
that. Please feel free to skip parts that are not necessary for your
understanding.
---
`WasmEHFuncInfo` contains the mapping of <EH pad, the EH pad's next
unwind destination>. The value (unwind dest) here is where an exception
should end up when it is not caught by the key (EH pad). We record this
info in WasmEHPrepare to fix catch mismatches, because the CFG itself
does not have this info. A CFG only contains BBs and
predecessor-successor relationship between them, but in `WasmEHFuncInfo`
the unwind destination BB is not necessarily a successor or the key EH
pad BB. Their relationship can be intuitively explained by this C++ code
snippet:
```
try {
try {
foo();
} catch (int) { // EH pad
...
}
} catch (...) { // unwind destination
}
```
So when `foo()` throws, it goes to `catch (int)` first. But if it is not
caught by it, it ends up in the next unwind destination `catch (...)`.
This unwind destination is what you see in `catchswitch`'s
`unwind label %bb` part.
---
`WebAssemblyExceptionInfo` groups exceptions so that they can be sorted
continuously together in CFGSort, as we do for loops. What this analysis
does is very simple: it creates a single `WebAssemblyException` per EH
pad, and all BBs that are dominated by that EH pad are included in this
exception. We also identify subexception relationship in this way: if
EHPad A domiantes EHPad B, EHPad B's exception is a subexception of
EHPad A's exception.
This simple rule turns out to be incorrect in some cases. In
`WasmEHFuncInfo`, if EHPad A's unwind destination is EHPad B, it means
semantically EHPad B should not be included in EHPad A's exception,
because it does not make sense to rethrow/delegate to an inner scope.
This is what happened in CFGStackify as a result of this:
```
try
try
catch
... <- %dest_bb is among here!
end
delegate %dest_bb
```
So this patch adds a phase in `WebAssemblyExceptionInfo::recalculate` to
make sure excptions' unwind destinations are not subexceptions of
their unwind sources in `WasmEHFuncInfo`.
But this alone does not prevent `dest_bb` in the example above from
being sorted within the inner `catch`'s exception, even if its exception
is not a subexception of that `catch`'s exception anymore, because of
how CFGSort works, which will be explained below.
---
CFGSort places BBs within the same `SortRegion` (loop or exception)
continuously together so they can be demarcated with `loop`-`end_loop`
or `catch`-`end_try` in CFGStackify.
`SortRegion` is a wrapper for one of `MachineLoop` or
`WebAssemblyException`. `SortRegionInfo` already does some complicated
things because there discrepancies between those two data structures.
`WebAssemblyException` is what we control, and it is defined as an EH
pad as its header and BBs dominated by the header as its BBs (with a
newly added exception of unwind destinations explained in the previous
paragraph). But `MachineLoop` is an LLVM data structure and uses the
standard loop detection algorithm. So by the algorithm, BBs that are 1.
dominated by the loop header and 2. have a path back to its header.
Because of the second condition, many BBs that are dominated by the loop
header are not included in the loop. So BBs that contain `return` or
branches to outside of the loop are not technically included in
`MachineLoop`, but they can be sorted together with the loop with no
problem.
Maybe to relax the condition, in CFGSort, when we are in a `SortRegion`
we allow sorting of not only BBs that belong to the current innermost
region but also BBs that are by the current region header.
(This was written this way from the first version written by Dan, when
only loops existed.) But now, we have cases in exceptions when EHPad B
is the unwind destination for EHPad A, even if EHPad B is dominated by
EHPad A it should not be included in EHPad A's exception, and should not
be sorted within EHPad A.
One way to make things work, at least correctly, is change `dominates`
condition to `contains` condition for `SortRegion` when sorting BBs, but
this will change compilation results for existing non-EH code and I
can't be sure it will not degrade performance or code size. I think it
will degrade performance because it will force many BBs dominated by a
loop, which don't have the path back to the header, to be placed after
the loop and it will likely to create more branches and blocks.
So this does a little hacky check when adding BBs to `Preferred` list:
(`Preferred` list is a ready list. CFGSort maintains ready list in two
priority queues: `Preferred` and `Ready`. I'm not very sure why, but it
was written that way from the beginning. BBs are first added to
`Preferred` list and then some of them are pushed to `Ready` list, so
here we only need to guard condition for `Preferred` list.)
When adding a BB to `Preferred` list, we check if that BB is an unwind
destination of another BB. To do this, this adds the reverse mapping,
`UnwindDestToSrc`, and getter methods to `WasmEHFuncInfo`. And if the BB
is an unwind destination, it checks if the current stack of regions
(`Entries`) contains its source BB by traversing the stack backwards. If
we find its unwind source in there, we add the BB to its `Deferred`
list, to make sure that unwind destination BB is added to `Preferred`
list only after that region with the unwind source BB is sorted and
popped from the stack.
---
This does not contain a new test that crashes because of this bug, but
this fix changes the result for one of existing test case. This test
case didn't crash because it fortunately didn't contain `delegate` to
the incorrectly placed unwind destination BB.
Fixes https://github.com/emscripten-core/emscripten/issues/13514.
Reviewed By: dschuff, tlively
Differential Revision: https://reviews.llvm.org/D97247
2021-02-17 14:08:52 +01:00
|
|
|
}
|
2021-02-26 21:23:24 +01:00
|
|
|
EHInfo.UnwindDestToSrcs = std::move(UnwindDestToSrcs);
|
2015-10-06 22:30:33 +02:00
|
|
|
}
|
2015-04-21 20:23:57 +02:00
|
|
|
}
|
|
|
|
|
2009-11-23 18:16:22 +01:00
|
|
|
/// clear - Clear out all the function-specific state. This returns this
|
|
|
|
/// FunctionLoweringInfo to an empty state, ready to be used for a
|
|
|
|
/// different function.
|
|
|
|
void FunctionLoweringInfo::clear() {
|
|
|
|
MBBMap.clear();
|
|
|
|
ValueMap.clear();
|
[AMDGPU] Fix issues for backend divergence tracking
Summary:
A change to use divergence analysis in the AMDGPU backend was getting formal
arguments incorrect (not tagged as divergent) unless they were VGPR0, VGPR1 or
VGPR2
For graphics shaders it is possible to have more than these passed in as VGPR
Modified the checking code to check for any VGPR registers passed in as formal
arguments.
Also, some intrinsics that are sources of divergence may have been lowered
during instruction selection and are missed on subsequent calls to
isSDNodeSourceOfDivergence - added the relevant AMDGPUISD checks as well.
Finally, the FunctionLoweringInfo tracks virtual registers that are live across
basic block boundaries. This is used to check for divergence of CopyFromRegister
registers using the DivergenceAnalysis analysis. For multiple blocks the lazily
evaluated inverted map VirtReg2Value was not cleared when the ValueMap map was.
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D45372
Change-Id: I112f3bd6dfe0f62e63ce9b43b893982778e4bee3
llvm-svn: 330257
2018-04-18 15:53:31 +02:00
|
|
|
VirtReg2Value.clear();
|
2009-11-23 18:16:22 +01:00
|
|
|
StaticAllocaMap.clear();
|
|
|
|
LiveOutRegInfo.clear();
|
2011-02-24 11:00:13 +01:00
|
|
|
VisitedBBs.clear();
|
2010-04-29 01:08:54 +02:00
|
|
|
ArgDbgValues.clear();
|
[SelectionDAGBuilder] Add restrictions to EmitFuncArgumentDbgValue
Summary:
This patch fixes PR40587.
When a dbg.value instrinsic is emitted to the DAG
by using EmitFuncArgumentDbgValue the resulting
DBG_VALUE is hoisted to the beginning of the entry
block. I think the idea is to be able to locate
a formal argument already from the start of the
function.
However, EmitFuncArgumentDbgValue only checked that
the value that was used to describe a variable was
originating from a function parameter, not that the
variable itself actually was an argument to the
function. So when for example assigning a local
variable "local" the value from an argument "a",
the assocated DBG_VALUE instruction would be hoisted
to the beginning of the function, even if the scope
for "local" started somewhere else (or if "local"
was mapped to other values earlier in the function).
This patch adds some logic to EmitFuncArgumentDbgValue
to check that the variable being described actually
is an argument to the function. And that the dbg.value
being lowered already is in the entry block. Otherwise
we bail out, and the dbg.value will be handled as an
ordinary dbg.value (not as a "FuncArgumentDbgValue").
A tricky situation is when both the variable and
the value is related to function arguments, but not
neccessarily the same argument. We make sure that we
do not describe the same argument more than once as
a "FuncArgumentDbgValue". This solution works as long
as opt has injected a "first" dbg.value that corresponds
to the formal argument at the function entry.
Reviewers: jmorse, aprantl
Subscribers: jyknight, hiraditya, fedor.sergeev, dstenb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57702
llvm-svn: 353735
2019-02-11 20:23:30 +01:00
|
|
|
DescribedArgs.clear();
|
2010-09-01 00:22:42 +02:00
|
|
|
ByValArgFrameIndexMap.clear();
|
2010-07-10 11:00:22 +02:00
|
|
|
RegFixups.clear();
|
[FastISel] Sink local value materializations to first use
Summary:
Local values are constants, global addresses, and stack addresses that
can't be folded into the instruction that uses them. For example, when
storing the address of a global variable into memory, we need to
materialize that address into a register.
FastISel doesn't want to materialize any given local value more than
once, so it generates all local value materialization code at
EmitStartPt, which always dominates the current insertion point. This
allows it to maintain a map of local value registers, and it knows that
the local value area will always dominate the current insertion point.
The downside is that local value instructions are always emitted without
a source location. This is done to prevent jumpy line tables, but it
means that the local value area will be considered part of the previous
statement. Consider this C code:
call1(); // line 1
++global; // line 2
++global; // line 3
call2(&global, &local); // line 4
Today we end up with assembly and line tables like this:
.loc 1 1
callq call1
leaq global(%rip), %rdi
leaq local(%rsp), %rsi
.loc 1 2
addq $1, global(%rip)
.loc 1 3
addq $1, global(%rip)
.loc 1 4
callq call2
The LEA instructions in the local value area have no source location and
are treated as being on line 1. Stepping through the code in a debugger
and correlating it with the assembly won't make much sense, because
these materializations are only required for line 4.
This is actually problematic for the VS debugger "set next statement"
feature, which effectively assumes that there are no registers live
across statement boundaries. By sinking the local value code into the
statement and fixing up the source location, we can make that feature
work. This was filed as https://bugs.llvm.org/show_bug.cgi?id=35975 and
https://crbug.com/793819.
This change is obviously not enough to make this feature work reliably
in all cases, but I felt that it was worth doing anyway because it
usually generates smaller, more comprehensible -O0 code. I measured a
0.12% regression in code generation time with LLC on the sqlite3
amalgamation, so I think this is worth doing.
There are some special cases worth calling out in the commit message:
1. local values materialized for phis
2. local values used by no-op casts
3. dead local value code
Local values can be materialized for phis, and this does not show up as
a vreg use in MachineRegisterInfo. In this case, if there are no other
uses, this patch sinks the value to the first terminator, EH label, or
the end of the BB if nothing else exists.
Local values may also be used by no-op casts, which adds the register to
the RegFixups table. Without reversing the RegFixups map direction, we
don't have enough information to sink these instructions.
Lastly, if the local value register has no other uses, we can delete it.
This comes up when fastisel tries two instruction selection approaches
and the first materializes the value but fails and the second succeeds
without using the local value.
Reviewers: aprantl, dblaikie, qcolombet, MatzeB, vsk, echristo
Subscribers: dotdash, chandlerc, hans, sdardis, amccarth, javed.absar, zturner, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D43093
llvm-svn: 327581
2018-03-14 22:54:21 +01:00
|
|
|
RegsWithFixups.clear();
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
StatepointStackSlots.clear();
|
2020-07-29 20:41:40 +02:00
|
|
|
StatepointRelocationMaps.clear();
|
2014-09-24 05:22:56 +02:00
|
|
|
PreferredExtendType.clear();
|
2009-11-23 18:16:22 +01:00
|
|
|
}
|
|
|
|
|
2010-07-02 02:10:16 +02:00
|
|
|
/// CreateReg - Allocate a single virtual register for the given type.
|
2020-04-08 18:26:32 +02:00
|
|
|
Register FunctionLoweringInfo::CreateReg(MVT VT, bool isDivergent) {
|
2014-08-04 23:25:23 +02:00
|
|
|
return RegInfo->createVirtualRegister(
|
2019-05-26 22:33:26 +02:00
|
|
|
MF->getSubtarget().getTargetLowering()->getRegClassFor(VT, isDivergent));
|
2009-11-23 18:16:22 +01:00
|
|
|
}
|
|
|
|
|
2010-07-02 02:10:16 +02:00
|
|
|
/// CreateRegs - Allocate the appropriate number of virtual registers of
|
2009-11-23 18:16:22 +01:00
|
|
|
/// the correctly promoted or expanded types. Assign these registers
|
|
|
|
/// consecutive vreg numbers and return the first assigned number.
|
|
|
|
///
|
|
|
|
/// In the case that the given value has struct or array type, this function
|
|
|
|
/// will assign registers for each member or element.
|
|
|
|
///
|
2020-04-08 18:26:32 +02:00
|
|
|
Register FunctionLoweringInfo::CreateRegs(Type *Ty, bool isDivergent) {
|
2014-10-09 02:57:31 +02:00
|
|
|
const TargetLowering *TLI = MF->getSubtarget().getTargetLowering();
|
2013-06-19 22:32:16 +02:00
|
|
|
|
2009-11-23 18:16:22 +01:00
|
|
|
SmallVector<EVT, 4> ValueVTs;
|
2015-07-09 03:57:34 +02:00
|
|
|
ComputeValueVTs(*TLI, MF->getDataLayout(), Ty, ValueVTs);
|
2009-11-23 18:16:22 +01:00
|
|
|
|
2020-04-08 18:26:32 +02:00
|
|
|
Register FirstReg;
|
2009-11-23 18:16:22 +01:00
|
|
|
for (unsigned Value = 0, e = ValueVTs.size(); Value != e; ++Value) {
|
|
|
|
EVT ValueVT = ValueVTs[Value];
|
2013-06-06 02:11:39 +02:00
|
|
|
MVT RegisterVT = TLI->getRegisterType(Ty->getContext(), ValueVT);
|
2009-11-23 18:16:22 +01:00
|
|
|
|
2013-06-06 02:11:39 +02:00
|
|
|
unsigned NumRegs = TLI->getNumRegisters(Ty->getContext(), ValueVT);
|
2009-11-23 18:16:22 +01:00
|
|
|
for (unsigned i = 0; i != NumRegs; ++i) {
|
2020-04-08 18:26:32 +02:00
|
|
|
Register R = CreateReg(RegisterVT, isDivergent);
|
2009-11-23 18:16:22 +01:00
|
|
|
if (!FirstReg) FirstReg = R;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return FirstReg;
|
|
|
|
}
|
2009-11-23 18:42:46 +01:00
|
|
|
|
2020-04-08 18:26:32 +02:00
|
|
|
Register FunctionLoweringInfo::CreateRegs(const Value *V) {
|
2020-05-26 18:58:18 +02:00
|
|
|
return CreateRegs(V->getType(), DA && DA->isDivergent(V) &&
|
|
|
|
!TLI->requiresUniformRegister(*MF, V));
|
2019-05-26 22:33:26 +02:00
|
|
|
}
|
|
|
|
|
2011-02-24 11:00:25 +01:00
|
|
|
/// GetLiveOutRegInfo - Gets LiveOutInfo for a register, returning NULL if the
|
|
|
|
/// register is a PHI destination and the PHI's LiveOutInfo is not valid. If
|
|
|
|
/// the register's LiveOutInfo is for a smaller bit width, it is extended to
|
|
|
|
/// the larger bit width by zero extension. The bit width must be no smaller
|
|
|
|
/// than the LiveOutInfo's existing bit width.
|
|
|
|
const FunctionLoweringInfo::LiveOutInfo *
|
2020-04-08 18:26:32 +02:00
|
|
|
FunctionLoweringInfo::GetLiveOutRegInfo(Register Reg, unsigned BitWidth) {
|
2011-02-24 11:00:25 +01:00
|
|
|
if (!LiveOutRegInfo.inBounds(Reg))
|
2014-04-14 02:51:57 +02:00
|
|
|
return nullptr;
|
2011-02-24 11:00:25 +01:00
|
|
|
|
|
|
|
LiveOutInfo *LOI = &LiveOutRegInfo[Reg];
|
|
|
|
if (!LOI->IsValid)
|
2014-04-14 02:51:57 +02:00
|
|
|
return nullptr;
|
2011-02-24 11:00:25 +01:00
|
|
|
|
2017-04-28 07:31:46 +02:00
|
|
|
if (BitWidth > LOI->Known.getBitWidth()) {
|
2011-02-25 02:11:01 +01:00
|
|
|
LOI->NumSignBits = 1;
|
2020-02-12 14:27:28 +01:00
|
|
|
LOI->Known = LOI->Known.anyext(BitWidth);
|
2011-02-24 11:00:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return LOI;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// ComputePHILiveOutRegInfo - Compute LiveOutInfo for a PHI's destination
|
|
|
|
/// register based on the LiveOutInfo of its operands.
|
|
|
|
void FunctionLoweringInfo::ComputePHILiveOutRegInfo(const PHINode *PN) {
|
2011-07-18 06:54:35 +02:00
|
|
|
Type *Ty = PN->getType();
|
2011-02-24 11:00:25 +01:00
|
|
|
if (!Ty->isIntegerTy() || Ty->isVectorTy())
|
|
|
|
return;
|
|
|
|
|
|
|
|
SmallVector<EVT, 1> ValueVTs;
|
2015-07-09 03:57:34 +02:00
|
|
|
ComputeValueVTs(*TLI, MF->getDataLayout(), Ty, ValueVTs);
|
2011-02-24 11:00:25 +01:00
|
|
|
assert(ValueVTs.size() == 1 &&
|
|
|
|
"PHIs with non-vector integer types should have a single VT.");
|
|
|
|
EVT IntVT = ValueVTs[0];
|
|
|
|
|
2013-06-06 02:11:39 +02:00
|
|
|
if (TLI->getNumRegisters(PN->getContext(), IntVT) != 1)
|
2011-02-24 11:00:25 +01:00
|
|
|
return;
|
2013-06-06 02:11:39 +02:00
|
|
|
IntVT = TLI->getTypeToTransformTo(PN->getContext(), IntVT);
|
2011-02-24 11:00:25 +01:00
|
|
|
unsigned BitWidth = IntVT.getSizeInBits();
|
|
|
|
|
2020-04-08 18:26:32 +02:00
|
|
|
Register DestReg = ValueMap[PN];
|
2019-08-02 01:27:28 +02:00
|
|
|
if (!Register::isVirtualRegister(DestReg))
|
2011-02-24 11:00:25 +01:00
|
|
|
return;
|
|
|
|
LiveOutRegInfo.grow(DestReg);
|
|
|
|
LiveOutInfo &DestLOI = LiveOutRegInfo[DestReg];
|
|
|
|
|
|
|
|
Value *V = PN->getIncomingValue(0);
|
|
|
|
if (isa<UndefValue>(V) || isa<ConstantExpr>(V)) {
|
|
|
|
DestLOI.NumSignBits = 1;
|
2017-04-28 07:31:46 +02:00
|
|
|
DestLOI.Known = KnownBits(BitWidth);
|
2011-02-24 11:00:25 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ConstantInt *CI = dyn_cast<ConstantInt>(V)) {
|
|
|
|
APInt Val = CI->getValue().zextOrTrunc(BitWidth);
|
|
|
|
DestLOI.NumSignBits = Val.getNumSignBits();
|
2021-01-13 12:25:35 +01:00
|
|
|
DestLOI.Known = KnownBits::makeConstant(Val);
|
2011-02-24 11:00:25 +01:00
|
|
|
} else {
|
|
|
|
assert(ValueMap.count(V) && "V should have been placed in ValueMap when its"
|
|
|
|
"CopyToReg node was created.");
|
2020-04-08 18:26:32 +02:00
|
|
|
Register SrcReg = ValueMap[V];
|
2019-08-02 01:27:28 +02:00
|
|
|
if (!Register::isVirtualRegister(SrcReg)) {
|
2011-02-24 11:00:25 +01:00
|
|
|
DestLOI.IsValid = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
const LiveOutInfo *SrcLOI = GetLiveOutRegInfo(SrcReg, BitWidth);
|
|
|
|
if (!SrcLOI) {
|
|
|
|
DestLOI.IsValid = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
DestLOI = *SrcLOI;
|
|
|
|
}
|
|
|
|
|
2017-04-28 07:31:46 +02:00
|
|
|
assert(DestLOI.Known.Zero.getBitWidth() == BitWidth &&
|
|
|
|
DestLOI.Known.One.getBitWidth() == BitWidth &&
|
2011-02-24 11:00:25 +01:00
|
|
|
"Masks should have the same bit width as the type.");
|
|
|
|
|
|
|
|
for (unsigned i = 1, e = PN->getNumIncomingValues(); i != e; ++i) {
|
|
|
|
Value *V = PN->getIncomingValue(i);
|
|
|
|
if (isa<UndefValue>(V) || isa<ConstantExpr>(V)) {
|
|
|
|
DestLOI.NumSignBits = 1;
|
2017-04-28 07:31:46 +02:00
|
|
|
DestLOI.Known = KnownBits(BitWidth);
|
2011-06-09 01:55:35 +02:00
|
|
|
return;
|
2011-02-24 11:00:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ConstantInt *CI = dyn_cast<ConstantInt>(V)) {
|
|
|
|
APInt Val = CI->getValue().zextOrTrunc(BitWidth);
|
|
|
|
DestLOI.NumSignBits = std::min(DestLOI.NumSignBits, Val.getNumSignBits());
|
2017-04-28 07:31:46 +02:00
|
|
|
DestLOI.Known.Zero &= ~Val;
|
|
|
|
DestLOI.Known.One &= Val;
|
2011-02-24 11:00:25 +01:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(ValueMap.count(V) && "V should have been placed in ValueMap when "
|
|
|
|
"its CopyToReg node was created.");
|
2020-04-08 18:26:32 +02:00
|
|
|
Register SrcReg = ValueMap[V];
|
|
|
|
if (!SrcReg.isVirtual()) {
|
2011-02-24 11:00:25 +01:00
|
|
|
DestLOI.IsValid = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
const LiveOutInfo *SrcLOI = GetLiveOutRegInfo(SrcReg, BitWidth);
|
|
|
|
if (!SrcLOI) {
|
|
|
|
DestLOI.IsValid = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
DestLOI.NumSignBits = std::min(DestLOI.NumSignBits, SrcLOI->NumSignBits);
|
2021-01-13 11:57:20 +01:00
|
|
|
DestLOI.Known = KnownBits::commonBits(DestLOI.Known, SrcLOI->Known);
|
2011-02-24 11:00:25 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-09 00:59:09 +02:00
|
|
|
/// setArgumentFrameIndex - Record frame index for the byval
|
2010-09-01 00:22:42 +02:00
|
|
|
/// argument. This overrides previous frame index entry for this argument,
|
|
|
|
/// if any.
|
2011-09-09 00:59:09 +02:00
|
|
|
void FunctionLoweringInfo::setArgumentFrameIndex(const Argument *A,
|
2012-02-24 02:59:01 +01:00
|
|
|
int FI) {
|
2010-09-01 00:22:42 +02:00
|
|
|
ByValArgFrameIndexMap[A] = FI;
|
|
|
|
}
|
2011-06-09 01:55:35 +02:00
|
|
|
|
2011-09-09 00:59:09 +02:00
|
|
|
/// getArgumentFrameIndex - Get frame index for the byval argument.
|
2010-09-01 00:22:42 +02:00
|
|
|
/// If the argument does not have any assigned frame index then 0 is
|
|
|
|
/// returned.
|
2011-09-09 00:59:09 +02:00
|
|
|
int FunctionLoweringInfo::getArgumentFrameIndex(const Argument *A) {
|
2017-05-09 18:02:20 +02:00
|
|
|
auto I = ByValArgFrameIndexMap.find(A);
|
2010-09-01 00:22:42 +02:00
|
|
|
if (I != ByValArgFrameIndexMap.end())
|
|
|
|
return I->second;
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << "Argument does not have assigned frame index!\n");
|
2017-05-09 18:02:20 +02:00
|
|
|
return INT_MAX;
|
2010-09-01 00:22:42 +02:00
|
|
|
}
|
|
|
|
|
2020-04-08 18:26:32 +02:00
|
|
|
Register FunctionLoweringInfo::getCatchPadExceptionPointerVReg(
|
2015-10-07 02:27:33 +02:00
|
|
|
const Value *CPI, const TargetRegisterClass *RC) {
|
|
|
|
MachineRegisterInfo &MRI = MF->getRegInfo();
|
|
|
|
auto I = CatchPadExceptionPointers.insert({CPI, 0});
|
2020-04-08 18:26:32 +02:00
|
|
|
Register &VReg = I.first->second;
|
2015-10-07 02:27:33 +02:00
|
|
|
if (I.second)
|
|
|
|
VReg = MRI.createVirtualRegister(RC);
|
|
|
|
assert(VReg && "null vreg in exception pointer table!");
|
|
|
|
return VReg;
|
|
|
|
}
|
|
|
|
|
2018-03-05 16:12:21 +01:00
|
|
|
const Value *
|
2020-04-08 18:26:32 +02:00
|
|
|
FunctionLoweringInfo::getValueFromVirtualReg(Register Vreg) {
|
2018-03-05 16:12:21 +01:00
|
|
|
if (VirtReg2Value.empty()) {
|
AMDGPU: Fix various issues around the VirtReg2Value mapping
Summary:
The VirtReg2Value mapping is crucial for getting consistently
reliable divergence information into the SelectionDAG. This
patch fixes a bunch of issues that lead to incorrect divergence
info and introduces tight assertions to ensure we don't regress:
1. VirtReg2Value is generated lazily; there were some cases where
a lookup was performed before all relevant virtual registers were
created, leading to an out-of-sync mapping. Those cases were:
- Complex code to lower formal arguments that generated CopyFromReg
nodes from live-in registers (fixed by never querying the mapping
for live-in registers).
- Code that generates CopyToReg for formal arguments that are used
outside the entry basic block (fixed by never querying the
mapping for Register nodes, which don't need the divergence info
anyway).
2. For complex values that are lowered to a sequence of registers,
all registers must be reflected in the VirtReg2Value mapping.
I am not adding any new tests, since I'm not actually aware of any
bugs that these problems are causing with trunk as-is. However,
I recently added a test case (in r346423) which fails when D53283 is
applied without this change. Also, the new assertions should provide
most of the effective test coverage.
There is one test change in sdwa-peephole.ll. The underlying issue
is that since the divergence info is now correct, the DAGISel will
select V_OR_B32 directly instead of S_OR_B32. This leads to an extra
COPY which affects the behavior of MachineLICM in a way that ends up
with the S_MOV_B32 with the constant in a different basic block than
the V_OR_B32, which is presumably what defeats the peephole.
Reviewers: alex-t, arsenm, rampitec
Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D54340
llvm-svn: 348049
2018-11-30 23:55:29 +01:00
|
|
|
SmallVector<EVT, 4> ValueVTs;
|
2018-03-05 16:12:21 +01:00
|
|
|
for (auto &P : ValueMap) {
|
AMDGPU: Fix various issues around the VirtReg2Value mapping
Summary:
The VirtReg2Value mapping is crucial for getting consistently
reliable divergence information into the SelectionDAG. This
patch fixes a bunch of issues that lead to incorrect divergence
info and introduces tight assertions to ensure we don't regress:
1. VirtReg2Value is generated lazily; there were some cases where
a lookup was performed before all relevant virtual registers were
created, leading to an out-of-sync mapping. Those cases were:
- Complex code to lower formal arguments that generated CopyFromReg
nodes from live-in registers (fixed by never querying the mapping
for live-in registers).
- Code that generates CopyToReg for formal arguments that are used
outside the entry basic block (fixed by never querying the
mapping for Register nodes, which don't need the divergence info
anyway).
2. For complex values that are lowered to a sequence of registers,
all registers must be reflected in the VirtReg2Value mapping.
I am not adding any new tests, since I'm not actually aware of any
bugs that these problems are causing with trunk as-is. However,
I recently added a test case (in r346423) which fails when D53283 is
applied without this change. Also, the new assertions should provide
most of the effective test coverage.
There is one test change in sdwa-peephole.ll. The underlying issue
is that since the divergence info is now correct, the DAGISel will
select V_OR_B32 directly instead of S_OR_B32. This leads to an extra
COPY which affects the behavior of MachineLICM in a way that ends up
with the S_MOV_B32 with the constant in a different basic block than
the V_OR_B32, which is presumably what defeats the peephole.
Reviewers: alex-t, arsenm, rampitec
Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D54340
llvm-svn: 348049
2018-11-30 23:55:29 +01:00
|
|
|
ValueVTs.clear();
|
|
|
|
ComputeValueVTs(*TLI, Fn->getParent()->getDataLayout(),
|
|
|
|
P.first->getType(), ValueVTs);
|
|
|
|
unsigned Reg = P.second;
|
|
|
|
for (EVT VT : ValueVTs) {
|
|
|
|
unsigned NumRegisters = TLI->getNumRegisters(Fn->getContext(), VT);
|
|
|
|
for (unsigned i = 0, e = NumRegisters; i != e; ++i)
|
|
|
|
VirtReg2Value[Reg++] = P.first;
|
|
|
|
}
|
2018-03-05 16:12:21 +01:00
|
|
|
}
|
|
|
|
}
|
AMDGPU: Fix various issues around the VirtReg2Value mapping
Summary:
The VirtReg2Value mapping is crucial for getting consistently
reliable divergence information into the SelectionDAG. This
patch fixes a bunch of issues that lead to incorrect divergence
info and introduces tight assertions to ensure we don't regress:
1. VirtReg2Value is generated lazily; there were some cases where
a lookup was performed before all relevant virtual registers were
created, leading to an out-of-sync mapping. Those cases were:
- Complex code to lower formal arguments that generated CopyFromReg
nodes from live-in registers (fixed by never querying the mapping
for live-in registers).
- Code that generates CopyToReg for formal arguments that are used
outside the entry basic block (fixed by never querying the
mapping for Register nodes, which don't need the divergence info
anyway).
2. For complex values that are lowered to a sequence of registers,
all registers must be reflected in the VirtReg2Value mapping.
I am not adding any new tests, since I'm not actually aware of any
bugs that these problems are causing with trunk as-is. However,
I recently added a test case (in r346423) which fails when D53283 is
applied without this change. Also, the new assertions should provide
most of the effective test coverage.
There is one test change in sdwa-peephole.ll. The underlying issue
is that since the divergence info is now correct, the DAGISel will
select V_OR_B32 directly instead of S_OR_B32. This leads to an extra
COPY which affects the behavior of MachineLICM in a way that ends up
with the S_MOV_B32 with the constant in a different basic block than
the V_OR_B32, which is presumably what defeats the peephole.
Reviewers: alex-t, arsenm, rampitec
Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D54340
llvm-svn: 348049
2018-11-30 23:55:29 +01:00
|
|
|
return VirtReg2Value.lookup(Vreg);
|
2018-03-05 16:12:21 +01:00
|
|
|
}
|