maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Target/Mips/Mips16HardFloat.cpp

543 lines
16 KiB
C++
Raw Normal View History

Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
//===---- Mips16HardFloat.cpp for Mips16 Hard Float --------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file defines a pass needed for Mips16 Hard Float
//
//===----------------------------------------------------------------------===//
#include "Mips16HardFloat.h"
#include "llvm/IR/Module.h"
Re-sort all of the includes with ./utils/sort_includes.py so that subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
2014-01-07 19:48:04 +08:00
#include "llvm/IR/Value.h"
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
#include "llvm/Support/Debug.h"
#include "llvm/Support/raw_ostream.h"
Don't generate floating point stubs for mips16 code if the function is actually an instrinsic that will not occur in libc. This list here is not exhaustive but fixes the one places in test-suite where this occurs. I have filed a bug against myself to research the full list and add them to the array of such cases. In the future, actual stub generation will occur in a later phase and we won't need this code because we will know at that time during the compilation that in fact no helper function was even needed. llvm-svn: 188149
2013-08-12 05:30:27 +08:00
#include <algorithm>
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
#include <string>
[Modules] Fix potential ODR violations by sinking the DEBUG_TYPE definition below all of the header #include lines, lib/Target/... edition. llvm-svn: 206842
2014-04-22 10:41:26 +08:00
#define DEBUG_TYPE "mips16-hard-float"
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
static void inlineAsmOut
(LLVMContext &C, StringRef AsmString, BasicBlock *BB ) {
std::vector<llvm::Type *> AsmArgTypes;
std::vector<llvm::Value*> AsmArgs;
llvm::FunctionType *AsmFTy =
llvm::FunctionType::get(Type::getVoidTy(C),
AsmArgTypes, false);
llvm::InlineAsm *IA =
llvm::InlineAsm::get(AsmFTy, AsmString, "", true,
/* IsAlignStack */ false,
llvm::InlineAsm::AD_ATT);
CallInst::Create(IA, AsmArgs, "", BB);
}
namespace {
class InlineAsmHelper {
LLVMContext &C;
BasicBlock *BB;
public:
InlineAsmHelper(LLVMContext &C_, BasicBlock *BB_) :
C(C_), BB(BB_) {
}
void Out(StringRef AsmString) {
inlineAsmOut(C, AsmString, BB);
}
};
}
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
//
// Return types that matter for hard float are:
// float, double, complex float, and complex double
//
enum FPReturnVariant {
FRet, DRet, CFRet, CDRet, NoFPRet
};
//
// Determine which FP return type this function has
//
static FPReturnVariant whichFPReturnVariant(Type *T) {
switch (T->getTypeID()) {
case Type::FloatTyID:
return FRet;
case Type::DoubleTyID:
return DRet;
case Type::StructTyID:
if (T->getStructNumElements() != 2)
break;
if ((T->getContainedType(0)->isFloatTy()) &&
(T->getContainedType(1)->isFloatTy()))
return CFRet;
if ((T->getContainedType(0)->isDoubleTy()) &&
(T->getContainedType(1)->isDoubleTy()))
return CDRet;
break;
default:
break;
}
return NoFPRet;
}
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
//
// Parameter type that matter are float, (float, float), (float, double),
// double, (double, double), (double, float)
//
enum FPParamVariant {
FSig, FFSig, FDSig,
DSig, DDSig, DFSig, NoSig
};
// which floating point parameter signature variant we are dealing with
//
typedef Type::TypeID TypeID;
const Type::TypeID FloatTyID = Type::FloatTyID;
const Type::TypeID DoubleTyID = Type::DoubleTyID;
static FPParamVariant whichFPParamVariantNeeded(Function &F) {
switch (F.arg_size()) {
case 0:
return NoSig;
case 1:{
TypeID ArgTypeID = F.getFunctionType()->getParamType(0)->getTypeID();
switch (ArgTypeID) {
case FloatTyID:
return FSig;
case DoubleTyID:
return DSig;
default:
return NoSig;
}
}
default: {
TypeID ArgTypeID0 = F.getFunctionType()->getParamType(0)->getTypeID();
TypeID ArgTypeID1 = F.getFunctionType()->getParamType(1)->getTypeID();
switch(ArgTypeID0) {
case FloatTyID: {
switch (ArgTypeID1) {
case FloatTyID:
return FFSig;
case DoubleTyID:
return FDSig;
default:
return FSig;
}
}
case DoubleTyID: {
switch (ArgTypeID1) {
case FloatTyID:
return DFSig;
case DoubleTyID:
return DDSig;
default:
return DSig;
}
}
default:
return NoSig;
}
}
}
llvm_unreachable("can't get here");
}
// Figure out if we need float point based on the function parameters.
// We need to move variables in and/or out of floating point
// registers because of the ABI
//
static bool needsFPStubFromParams(Function &F) {
if (F.arg_size() >=1) {
Type *ArgType = F.getFunctionType()->getParamType(0);
switch (ArgType->getTypeID()) {
case Type::FloatTyID:
case Type::DoubleTyID:
return true;
default:
break;
}
}
return false;
}
static bool needsFPReturnHelper(Function &F) {
Type* RetType = F.getReturnType();
return whichFPReturnVariant(RetType) != NoFPRet;
}
Fix a problem with mips16 stubs when calls are transformed during tail call optimization. Some more work may be needed for indirect calls but this patch fixes the current regression in Prolangc++/trees. S2 optimization as part of the general cleanup and optimization of prolog and epilog was not saving S2 in this case and needed to. llvm-svn: 197630
2013-12-19 07:57:48 +08:00
static bool needsFPReturnHelper(const FunctionType &FT) {
Type* RetType = FT.getReturnType();
return whichFPReturnVariant(RetType) != NoFPRet;
}
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
static bool needsFPHelperFromSig(Function &F) {
return needsFPStubFromParams(F) || needsFPReturnHelper(F);
}
//
// We swap between FP and Integer registers to allow Mips16 and Mips32 to
// interoperate
//
Removed an unnamed namespace and forgot to make two of the functions inside "static". llvm-svn: 181754
2013-05-14 10:13:45 +08:00
static void swapFPIntParams
(FPParamVariant PV, Module *M, InlineAsmHelper &IAH,
bool LE, bool ToFP) {
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
//LLVMContext &Context = M->getContext();
std::string MI = ToFP? "mtc1 ": "mfc1 ";
switch (PV) {
case FSig:
IAH.Out(MI + "$$4,$$f12");
break;
case FFSig:
IAH.Out(MI +"$$4,$$f12");
IAH.Out(MI + "$$5,$$f14");
break;
case FDSig:
IAH.Out(MI + "$$4,$$f12");
if (LE) {
IAH.Out(MI + "$$6,$$f14");
IAH.Out(MI + "$$7,$$f15");
} else {
IAH.Out(MI + "$$7,$$f14");
IAH.Out(MI + "$$6,$$f15");
}
break;
case DSig:
if (LE) {
IAH.Out(MI + "$$4,$$f12");
IAH.Out(MI + "$$5,$$f13");
} else {
IAH.Out(MI + "$$5,$$f12");
IAH.Out(MI + "$$4,$$f13");
}
break;
case DDSig:
if (LE) {
IAH.Out(MI + "$$4,$$f12");
IAH.Out(MI + "$$5,$$f13");
IAH.Out(MI + "$$6,$$f14");
IAH.Out(MI + "$$7,$$f15");
} else {
IAH.Out(MI + "$$5,$$f12");
IAH.Out(MI + "$$4,$$f13");
IAH.Out(MI + "$$7,$$f14");
IAH.Out(MI + "$$6,$$f15");
}
break;
case DFSig:
if (LE) {
IAH.Out(MI + "$$4,$$f12");
IAH.Out(MI + "$$5,$$f13");
} else {
IAH.Out(MI + "$$5,$$f12");
IAH.Out(MI + "$$4,$$f13");
}
IAH.Out(MI + "$$6,$$f14");
break;
case NoSig:
return;
}
}
//
// Make sure that we know we already need a stub for this function.
// Having called needsFPHelperFromSig
//
This patch has two main functions: 1) Fix a specific bug when certain conversion functions are called in a program compiled as mips16 with hard float and the program is linked as c++. There are two libraries that are reversed in the link order with gcc/g++ and clang/clang++ for mips16 in this case and the proper stubs will then not be called. These stubs are normally handled in the Mips16HardFloat pass but in this case we don't know at that time that we need to generate the stubs. This must all be handled later in code generation and we have moved this functionality to MipsAsmPrinter. When linked as C (gcc or clang) the proper stubs are linked in from libc. 2) Set up the infrastructure to handle 90% of what is in the Mips16HardFloat pass in this new area of MipsAsmPrinter. This is a more logical place to handle this and we have known for some time that we needed to move the code later and not implement it using inline asm as we do now but it was not clear exactly where to do this and what mechanism should be used. Now it's clear to us how to do this and this patch contains the infrastructure to move most of this to MipsAsmPrinter but the actual moving will be done in a follow on patch. The same infrastructure is used to fix this current bug as described in #1. This change was requested by the list during the original putback of the Mips16HardFloat pass but was not practical for us do at that time. llvm-svn: 201426
2014-02-15 03:16:39 +08:00
static void assureFPCallStub(Function &F, Module *M,
const MipsSubtarget &Subtarget) {
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
// for now we only need them for static relocation
Fix typo. llvm-svn: 181759
2013-05-14 14:00:01 +08:00
if (Subtarget.getRelocationModel() == Reloc::PIC_)
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
return;
LLVMContext &Context = M->getContext();
bool LE = Subtarget.isLittle();
std::string Name = F.getName();
std::string SectionName = ".mips16.call.fp." + Name;
Fix some misc. issues with Mips16 fp stubs. 1) They should never be inlined. 2) A naming inconsistency with gcc mips16 3) Stubs should not have the global attribute llvm-svn: 187555
2013-08-01 10:26:31 +08:00
std::string StubName = "__call_stub_fp_" + Name;
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
//
// see if we already have the stub
//
Function *FStub = M->getFunction(StubName);
if (FStub && !FStub->isDeclaration()) return;
FStub = Function::Create(F.getFunctionType(),
Function::InternalLinkage, StubName, M);
FStub->addFnAttr("mips16_fp_stub");
FStub->addFnAttr(llvm::Attribute::Naked);
Fix some misc. issues with Mips16 fp stubs. 1) They should never be inlined. 2) A naming inconsistency with gcc mips16 3) Stubs should not have the global attribute llvm-svn: 187555
2013-08-01 10:26:31 +08:00
FStub->addFnAttr(llvm::Attribute::NoInline);
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
FStub->addFnAttr(llvm::Attribute::NoUnwind);
FStub->addFnAttr("nomips16");
FStub->setSection(SectionName);
BasicBlock *BB = BasicBlock::Create(Context, "entry", FStub);
InlineAsmHelper IAH(Context, BB);
Fix some misc. issues with Mips16 fp stubs. 1) They should never be inlined. 2) A naming inconsistency with gcc mips16 3) Stubs should not have the global attribute llvm-svn: 187555
2013-08-01 10:26:31 +08:00
IAH.Out(".set reorder");
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
FPReturnVariant RV = whichFPReturnVariant(FStub->getReturnType());
FPParamVariant PV = whichFPParamVariantNeeded(F);
swapFPIntParams(PV, M, IAH, LE, true);
if (RV != NoFPRet) {
IAH.Out("move $$18, $$31");
IAH.Out("jal " + Name);
} else {
IAH.Out("lui $$25,%hi(" + Name + ")");
IAH.Out("addiu $$25,$$25,%lo(" + Name + ")" );
}
switch (RV) {
case FRet:
IAH.Out("mfc1 $$2,$$f0");
break;
case DRet:
if (LE) {
IAH.Out("mfc1 $$2,$$f0");
IAH.Out("mfc1 $$3,$$f1");
} else {
IAH.Out("mfc1 $$3,$$f0");
IAH.Out("mfc1 $$2,$$f1");
}
break;
case CFRet:
if (LE) {
IAH.Out("mfc1 $$2,$$f0");
IAH.Out("mfc1 $$3,$$f2");
} else {
IAH.Out("mfc1 $$3,$$f0");
IAH.Out("mfc1 $$3,$$f2");
}
break;
case CDRet:
if (LE) {
IAH.Out("mfc1 $$4,$$f2");
IAH.Out("mfc1 $$5,$$f3");
IAH.Out("mfc1 $$2,$$f0");
IAH.Out("mfc1 $$3,$$f1");
} else {
IAH.Out("mfc1 $$5,$$f2");
IAH.Out("mfc1 $$4,$$f3");
IAH.Out("mfc1 $$3,$$f0");
IAH.Out("mfc1 $$2,$$f1");
}
break;
case NoFPRet:
break;
}
if (RV != NoFPRet)
IAH.Out("jr $$18");
else
IAH.Out("jr $$25");
new UnreachableInst(Context, BB);
}
Don't generate floating point stubs for mips16 code if the function is actually an instrinsic that will not occur in libc. This list here is not exhaustive but fixes the one places in test-suite where this occurs. I have filed a bug against myself to research the full list and add them to the array of such cases. In the future, actual stub generation will occur in a later phase and we won't need this code because we will know at that time during the compilation that in fact no helper function was even needed. llvm-svn: 188149
2013-08-12 05:30:27 +08:00
//
Make sure we don't generate stubs for any of these functions because they don't exist in libc. This is really not the right way to solve this problem; but it's not clear to me at this time exactly what is the right way. If we create stubs here, they will cause link errors because these functions do not exist in libc. llvm-svn: 189727
2013-09-01 12:12:59 +08:00
// Functions that are llvm intrinsics and don't need helpers.
Don't generate floating point stubs for mips16 code if the function is actually an instrinsic that will not occur in libc. This list here is not exhaustive but fixes the one places in test-suite where this occurs. I have filed a bug against myself to research the full list and add them to the array of such cases. In the future, actual stub generation will occur in a later phase and we won't need this code because we will know at that time during the compilation that in fact no helper function was even needed. llvm-svn: 188149
2013-08-12 05:30:27 +08:00
//
Remove global construction. const char* is sufficient here. No functionality change. llvm-svn: 188158
2013-08-12 17:37:29 +08:00
static const char *IntrinsicInline[] =
Make sure we don't generate stubs for any of these functions because they don't exist in libc. This is really not the right way to solve this problem; but it's not clear to me at this time exactly what is the right way. If we create stubs here, they will cause link errors because these functions do not exist in libc. llvm-svn: 189727
2013-09-01 12:12:59 +08:00
{"fabs",
Add fabsf to the list of inlined functions; otherwise Mips16 will try and create a stub for it and this will result in a link error because that function does not exist in libc. llvm-svn: 192223
2013-10-09 03:55:01 +08:00
"fabsf",
Make sure we don't generate stubs for any of these functions because they don't exist in libc. This is really not the right way to solve this problem; but it's not clear to me at this time exactly what is the right way. If we create stubs here, they will cause link errors because these functions do not exist in libc. llvm-svn: 189727
2013-09-01 12:12:59 +08:00
"llvm.ceil.f32", "llvm.ceil.f64",
"llvm.copysign.f32", "llvm.copysign.f64",
"llvm.cos.f32", "llvm.cos.f64",
"llvm.exp.f32", "llvm.exp.f64",
"llvm.exp2.f32", "llvm.exp2.f64",
"llvm.fabs.f32", "llvm.fabs.f64",
"llvm.floor.f32", "llvm.floor.f64",
"llvm.fma.f32", "llvm.fma.f64",
"llvm.log.f32", "llvm.log.f64",
"llvm.log10.f32", "llvm.log10.f64",
"llvm.nearbyint.f32", "llvm.nearbyint.f64",
"llvm.pow.f32", "llvm.pow.f64",
"llvm.powi.f32", "llvm.powi.f64",
"llvm.rint.f32", "llvm.rint.f64",
"llvm.round.f32", "llvm.round.f64",
"llvm.sin.f32", "llvm.sin.f64",
"llvm.sqrt.f32", "llvm.sqrt.f64",
"llvm.trunc.f32", "llvm.trunc.f64",
};
Don't generate floating point stubs for mips16 code if the function is actually an instrinsic that will not occur in libc. This list here is not exhaustive but fixes the one places in test-suite where this occurs. I have filed a bug against myself to research the full list and add them to the array of such cases. In the future, actual stub generation will occur in a later phase and we won't need this code because we will know at that time during the compilation that in fact no helper function was even needed. llvm-svn: 188149
2013-08-12 05:30:27 +08:00
Remove global construction. const char* is sufficient here. No functionality change. llvm-svn: 188158
2013-08-12 17:37:29 +08:00
static bool isIntrinsicInline(Function *F) {
Retire llvm::array_endof in favor of non-member std::end. While there make array_lengthof constexpr if we have support for it. llvm-svn: 206112
2014-04-13 00:15:53 +08:00
return std::binary_search(std::begin(IntrinsicInline),
std::end(IntrinsicInline), F->getName());
Don't generate floating point stubs for mips16 code if the function is actually an instrinsic that will not occur in libc. This list here is not exhaustive but fixes the one places in test-suite where this occurs. I have filed a bug against myself to research the full list and add them to the array of such cases. In the future, actual stub generation will occur in a later phase and we won't need this code because we will know at that time during the compilation that in fact no helper function was even needed. llvm-svn: 188149
2013-08-12 05:30:27 +08:00
}
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
//
// Returns of float, double and complex need to be handled with a helper
Patch number 2 for mips16/32 floating point interoperability stubs. This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
2013-05-16 10:17:42 +08:00
// function.
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
//
static bool fixupFPReturnAndCall
(Function &F, Module *M, const MipsSubtarget &Subtarget) {
bool Modified = false;
LLVMContext &C = M->getContext();
Type *MyVoid = Type::getVoidTy(C);
for (Function::iterator BB = F.begin(), E = F.end(); BB != E; ++BB)
for (BasicBlock::iterator I = BB->begin(), E = BB->end();
I != E; ++I) {
Instruction &Inst = *I;
if (const ReturnInst *RI = dyn_cast<ReturnInst>(I)) {
Value *RVal = RI->getReturnValue();
if (!RVal) continue;
//
// If there is a return value and it needs a helper function,
// figure out which one and add a call before the actual
// return to this helper. The purpose of the helper is to move
// floating point values from their soft float return mapping to
// where they would have been mapped to in floating point registers.
//
Type *T = RVal->getType();
FPReturnVariant RV = whichFPReturnVariant(T);
if (RV == NoFPRet) continue;
static const char* Helper[NoFPRet] =
{"__mips16_ret_sf", "__mips16_ret_df", "__mips16_ret_sc",
"__mips16_ret_dc"};
const char *Name = Helper[RV];
AttributeSet A;
Value *Params[] = {RVal};
Modified = true;
//
// These helper functions have a different calling ABI so
// this __Mips16RetHelper indicates that so that later
// during call setup, the proper call lowering to the helper
// functions will take place.
//
A = A.addAttribute(C, AttributeSet::FunctionIndex,
"__Mips16RetHelper");
A = A.addAttribute(C, AttributeSet::FunctionIndex,
Attribute::ReadNone);
Fix some misc. issues with Mips16 fp stubs. 1) They should never be inlined. 2) A naming inconsistency with gcc mips16 3) Stubs should not have the global attribute llvm-svn: 187555
2013-08-01 10:26:31 +08:00
A = A.addAttribute(C, AttributeSet::FunctionIndex,
Attribute::NoInline);
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
Value *F = (M->getOrInsertFunction(Name, A, MyVoid, T, NULL));
CallInst::Create(F, Params, "", &Inst );
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
} else if (const CallInst *CI = dyn_cast<CallInst>(I)) {
Fix a problem with mips16 stubs when calls are transformed during tail call optimization. Some more work may be needed for indirect calls but this patch fixes the current regression in Prolangc++/trees. S2 optimization as part of the general cleanup and optimization of prolog and epilog was not saving S2 in this case and needed to. llvm-svn: 197630
2013-12-19 07:57:48 +08:00
const Value* V = CI->getCalledValue();
[C++] Use 'nullptr'. Target edition. llvm-svn: 207197
2014-04-25 13:30:21 +08:00
const Type* T = nullptr;
Fix a problem with mips16 stubs when calls are transformed during tail call optimization. Some more work may be needed for indirect calls but this patch fixes the current regression in Prolangc++/trees. S2 optimization as part of the general cleanup and optimization of prolog and epilog was not saving S2 in this case and needed to. llvm-svn: 197630
2013-12-19 07:57:48 +08:00
if (V) T = V->getType();
[C++] Use 'nullptr'. Target edition. llvm-svn: 207197
2014-04-25 13:30:21 +08:00
const PointerType *PFT=nullptr;
Fix a problem with mips16 stubs when calls are transformed during tail call optimization. Some more work may be needed for indirect calls but this patch fixes the current regression in Prolangc++/trees. S2 optimization as part of the general cleanup and optimization of prolog and epilog was not saving S2 in this case and needed to. llvm-svn: 197630
2013-12-19 07:57:48 +08:00
if (T) PFT = dyn_cast<PointerType>(T);
[C++] Use 'nullptr'. Target edition. llvm-svn: 207197
2014-04-25 13:30:21 +08:00
const FunctionType *FT=nullptr;
Fix a problem with mips16 stubs when calls are transformed during tail call optimization. Some more work may be needed for indirect calls but this patch fixes the current regression in Prolangc++/trees. S2 optimization as part of the general cleanup and optimization of prolog and epilog was not saving S2 in this case and needed to. llvm-svn: 197630
2013-12-19 07:57:48 +08:00
if (PFT) FT = dyn_cast<FunctionType>(PFT->getElementType());
Next step in Mips16 prologue/epilogue cleanup. Save S2(reg 18) only when we are calling floating point stubs that have a return value of float or complex. Some more work to make this better but this is the first step. llvm-svn: 196921
2013-12-10 22:29:38 +08:00
Function *F_ = CI->getCalledFunction();
Fix a problem with mips16 stubs when calls are transformed during tail call optimization. Some more work may be needed for indirect calls but this patch fixes the current regression in Prolangc++/trees. S2 optimization as part of the general cleanup and optimization of prolog and epilog was not saving S2 in this case and needed to. llvm-svn: 197630
2013-12-19 07:57:48 +08:00
if (FT && needsFPReturnHelper(*FT) &&
!(F_ && isIntrinsicInline(F_))) {
Modified=true;
F.addFnAttr("saveS2");
}
Next step in Mips16 prologue/epilogue cleanup. Save S2(reg 18) only when we are calling floating point stubs that have a return value of float or complex. Some more work to make this better but this is the first step. llvm-svn: 196921
2013-12-10 22:29:38 +08:00
if (F_ && !isIntrinsicInline(F_)) {
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
// pic mode calls are handled by already defined
// helper functions
Next step in Mips16 prologue/epilogue cleanup. Save S2(reg 18) only when we are calling floating point stubs that have a return value of float or complex. Some more work to make this better but this is the first step. llvm-svn: 196921
2013-12-10 22:29:38 +08:00
if (needsFPReturnHelper(*F_)) {
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
Modified=true;
Next step in Mips16 prologue/epilogue cleanup. Save S2(reg 18) only when we are calling floating point stubs that have a return value of float or complex. Some more work to make this better but this is the first step. llvm-svn: 196921
2013-12-10 22:29:38 +08:00
F.addFnAttr("saveS2");
}
if (Subtarget.getRelocationModel() != Reloc::PIC_ ) {
if (needsFPHelperFromSig(*F_)) {
assureFPCallStub(*F_, M, Subtarget);
Modified=true;
}
This is the first of three patches which creates stubs used for Mips16/32 floating point interoperability. When Mips16 code calls external functions that would normally have some of its parameters or return values passed in floating point registers, it needs (Mips32) helper functions to do this because while in Mips16 mode there is no ability to access the floating point registers. In Pic mode, this is done with a set of predefined functions in libc. This case is already handled in llvm for Mips16. In static relocation mode, for efficiency reasons, the compiler generates stubs that the linker will use if it turns out that the external function is a Mips32 function. (If it's Mips16, then it does not need the helper stubs). These stubs are identically named and the linker knows about these tricks and will not create multiple copies and will delete them if they are not needed. llvm-svn: 181753
2013-05-14 10:00:24 +08:00
}
}
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
}
}
return Modified;
}
Patch number 2 for mips16/32 floating point interoperability stubs. This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
2013-05-16 10:17:42 +08:00
static void createFPFnStub(Function *F, Module *M, FPParamVariant PV,
const MipsSubtarget &Subtarget ) {
bool PicMode = Subtarget.getRelocationModel() == Reloc::PIC_;
bool LE = Subtarget.isLittle();
LLVMContext &Context = M->getContext();
std::string Name = F->getName();
std::string SectionName = ".mips16.fn." + Name;
std::string StubName = "__fn_stub_" + Name;
Fix a bad typo in the inline assembly code for mips16 pic fp stubs and make one cosmetic cleanup to make it look the same as gcc in this area; adjusting test cases. llvm-svn: 191400
2013-09-26 04:58:50 +08:00
std::string LocalName = "$$__fn_local_" + Name;
Patch number 2 for mips16/32 floating point interoperability stubs. This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
2013-05-16 10:17:42 +08:00
Function *FStub = Function::Create
(F->getFunctionType(),
Fix some misc. issues with Mips16 fp stubs. 1) They should never be inlined. 2) A naming inconsistency with gcc mips16 3) Stubs should not have the global attribute llvm-svn: 187555
2013-08-01 10:26:31 +08:00
Function::InternalLinkage, StubName, M);
Patch number 2 for mips16/32 floating point interoperability stubs. This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
2013-05-16 10:17:42 +08:00
FStub->addFnAttr("mips16_fp_stub");
FStub->addFnAttr(llvm::Attribute::Naked);
FStub->addFnAttr(llvm::Attribute::NoUnwind);
Fix some misc. issues with Mips16 fp stubs. 1) They should never be inlined. 2) A naming inconsistency with gcc mips16 3) Stubs should not have the global attribute llvm-svn: 187555
2013-08-01 10:26:31 +08:00
FStub->addFnAttr(llvm::Attribute::NoInline);
Patch number 2 for mips16/32 floating point interoperability stubs. This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
2013-05-16 10:17:42 +08:00
FStub->addFnAttr("nomips16");
FStub->setSection(SectionName);
BasicBlock *BB = BasicBlock::Create(Context, "entry", FStub);
InlineAsmHelper IAH(Context, BB);
IAH.Out(" .set macro");
if (PicMode) {
IAH.Out(".set noreorder");
Fix a bad typo in the inline assembly code for mips16 pic fp stubs and make one cosmetic cleanup to make it look the same as gcc in this area; adjusting test cases. llvm-svn: 191400
2013-09-26 04:58:50 +08:00
IAH.Out(".cpload $$25");
Patch number 2 for mips16/32 floating point interoperability stubs. This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
2013-05-16 10:17:42 +08:00
IAH.Out(".set reorder");
IAH.Out(".reloc 0,R_MIPS_NONE," + Name);
IAH.Out("la $$25," + LocalName);
}
Set .reorder for the stub so that gas takes care of delay slot processing. llvm-svn: 191125
2013-09-21 09:37:52 +08:00
else {
IAH.Out(".set reorder");
Fix a bad typo in the inline assembly code for mips16 pic fp stubs and make one cosmetic cleanup to make it look the same as gcc in this area; adjusting test cases. llvm-svn: 191400
2013-09-26 04:58:50 +08:00
IAH.Out("la $$25," + Name);
Set .reorder for the stub so that gas takes care of delay slot processing. llvm-svn: 191125
2013-09-21 09:37:52 +08:00
}
Patch number 2 for mips16/32 floating point interoperability stubs. This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
2013-05-16 10:17:42 +08:00
swapFPIntParams(PV, M, IAH, LE, false);
IAH.Out("jr $$25");
IAH.Out(LocalName + " = " + Name);
new UnreachableInst(FStub->getContext(), BB);
}
Fix a problem with dual mips16/mips32 mode. When the underlying processor has hard float, when you compile the mips32 code you have to make sure that it knows to compile any mips32 routines as hard float. I need to clean up the way mips16 hard float is specified but I need to first think through all the details. Mips16 always has a form of soft float, the difference being whether the underlying hardware has floating point. So it's not really necessary to pass the -soft-float to llvm since soft-float is always true for mips16 by virtue of the fact that it will not register floating point registers. By using this fact, I can simplify the way this is all handled. llvm-svn: 189690
2013-08-31 03:40:56 +08:00
//
// remove the use-soft-float attribute
//
static void removeUseSoftFloat(Function &F) {
AttributeSet A;
DEBUG(errs() << "removing -use-soft-float\n");
A = A.addAttribute(F.getContext(), AttributeSet::FunctionIndex,
"use-soft-float", "false");
F.removeAttributes(AttributeSet::FunctionIndex, A);
if (F.hasFnAttribute("use-soft-float")) {
DEBUG(errs() << "still has -use-soft-float\n");
}
F.addAttributes(AttributeSet::FunctionIndex, A);
}
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
namespace llvm {
//
// This pass only makes sense when the underlying chip has floating point but
// we are compiling as mips16.
// For all mips16 functions (that are not stubs we have already generated), or
// declared via attributes as nomips16, we must:
// 1) fixup all returns of float, double, single and double complex
// by calling a helper function before the actual return.
This patch has two main functions: 1) Fix a specific bug when certain conversion functions are called in a program compiled as mips16 with hard float and the program is linked as c++. There are two libraries that are reversed in the link order with gcc/g++ and clang/clang++ for mips16 in this case and the proper stubs will then not be called. These stubs are normally handled in the Mips16HardFloat pass but in this case we don't know at that time that we need to generate the stubs. This must all be handled later in code generation and we have moved this functionality to MipsAsmPrinter. When linked as C (gcc or clang) the proper stubs are linked in from libc. 2) Set up the infrastructure to handle 90% of what is in the Mips16HardFloat pass in this new area of MipsAsmPrinter. This is a more logical place to handle this and we have known for some time that we needed to move the code later and not implement it using inline asm as we do now but it was not clear exactly where to do this and what mechanism should be used. Now it's clear to us how to do this and this patch contains the infrastructure to move most of this to MipsAsmPrinter but the actual moving will be done in a follow on patch. The same infrastructure is used to fix this current bug as described in #1. This change was requested by the list during the original putback of the Mips16HardFloat pass but was not practical for us do at that time. llvm-svn: 201426
2014-02-15 03:16:39 +08:00
// 2) generate helper functions (stubs) that can be called by mips32
// functions that will move parameters passed normally passed in
// floating point
Patch number 2 for mips16/32 floating point interoperability stubs. This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
2013-05-16 10:17:42 +08:00
// registers the soft float equivalents.
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
// 3) in the case of static relocation, generate helper functions so that
// mips16 functions can call extern functions of unknown type (mips16 or
Patch number 2 for mips16/32 floating point interoperability stubs. This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
2013-05-16 10:17:42 +08:00
// mips32).
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
// 4) TBD. For pic, calls to extern functions of unknown type are handled by
// predefined helper functions in libc but this work is currently done
// during call lowering but it should be moved here in the future.
//
bool Mips16HardFloat::runOnModule(Module &M) {
DEBUG(errs() << "Run on Module Mips16HardFloat\n");
bool Modified = false;
for (Module::iterator F = M.begin(), E = M.end(); F != E; ++F) {
Fix a problem with dual mips16/mips32 mode. When the underlying processor has hard float, when you compile the mips32 code you have to make sure that it knows to compile any mips32 routines as hard float. I need to clean up the way mips16 hard float is specified but I need to first think through all the details. Mips16 always has a form of soft float, the difference being whether the underlying hardware has floating point. So it's not really necessary to pass the -soft-float to llvm since soft-float is always true for mips16 by virtue of the fact that it will not register floating point registers. By using this fact, I can simplify the way this is all handled. llvm-svn: 189690
2013-08-31 03:40:56 +08:00
if (F->hasFnAttribute("nomips16") &&
F->hasFnAttribute("use-soft-float")) {
removeUseSoftFloat(*F);
continue;
}
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
if (F->isDeclaration() || F->hasFnAttribute("mips16_fp_stub") ||
F->hasFnAttribute("nomips16")) continue;
Modified |= fixupFPReturnAndCall(*F, &M, Subtarget);
Patch number 2 for mips16/32 floating point interoperability stubs. This creates stubs that help Mips32 functions call Mips16 functions which have floating point parameters that are normally passed in floating point registers. llvm-svn: 181972
2013-05-16 10:17:42 +08:00
FPParamVariant V = whichFPParamVariantNeeded(*F);
if (V != NoSig) {
Modified = true;
createFPFnStub(F, &M, V, Subtarget);
}
Checkin in of first of several patches to finish implementation of mips16/mips32 floating point interoperability. This patch fixes returns from mips16 functions so that if the function was in fact called by a mips32 hard float routine, then values that would have been returned in floating point registers are so returned. Mips16 mode has no floating point instructions so there is no way to load values into floating point registers. This is needed when returning float, double, single complex, double complex in the Mips ABI. Helper functions in libc for mips16 are available to do this. For efficiency purposes, these helper functions have a different calling convention from normal Mips calls. Registers v0,v1,a0,a1 are used to pass parameters instead of a0,a1,a2,a3. This is because v0,v1,a0,a1 are the natural registers used to return floating point values in soft float. These values can then be moved to the appropriate floating point registers with no extra cost. The only register that is modified is ra in this call. The helper functions make sure that the return values are in the floating point registers that they would be in if soft float was not in effect (which it is for mips16, though the soft float is implemented using a mips32 library that uses hard float). llvm-svn: 181641
2013-05-11 06:25:39 +08:00
}
return Modified;
}
char Mips16HardFloat::ID = 0;
}
ModulePass *llvm::createMips16HardFloat(MipsTargetMachine &TM) {
return new Mips16HardFloat(TM);
}