llvm-6502/lib/Target/Mips/MipsOs16.cpp

147 lines
4.0 KiB
C++
Raw Normal View History

//===---- MipsOs16.cpp for Mips Option -Os16 --------===//
This is for an experimental option -mips-os16. The idea is to compile all Mips32 code as Mips16 unless it can't be compiled as Mips 16. For now this would happen as long as floating point instructions are not needed. Probably it would also make sense to compile as mips32 if atomic operations are needed too. There may be other cases too. A module pass prescans the IR and adds the mips16 or nomips16 attribute to functions depending on the functions needs. Mips 16 mode can result in a 40% code compression by utililizing 16 bit encoding of many instructions. The hope is for this to replace the traditional gcc way of dealing with Mips16 code using floating point which involves essentially using soft float but with a library implemented using mips32 floating point. This gcc method also requires creating stubs so that Mips32 code can interact with these Mips 16 functions that have floating point needs. My conjecture is that in reality this traditional gcc method would never win over this new method. I will be implementing the traditional gcc method also. Some of it is already done but I needed to do the stubs to finish the work and those required this mips16/32 mixed mode capability. I have more ideas for to make this new method much better and I think the old method will just live in llvm for anyone that needs the backward compatibility but I don't for what reason that would be needed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179185 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-10 16:58:04 +00:00
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file defines an optimization phase for the MIPS target.
//
//===----------------------------------------------------------------------===//
#define DEBUG_TYPE "mips-os16"
#include "MipsOs16.h"
#include "llvm/IR/Module.h"
#include "llvm/Support/CommandLine.h"
This is for an experimental option -mips-os16. The idea is to compile all Mips32 code as Mips16 unless it can't be compiled as Mips 16. For now this would happen as long as floating point instructions are not needed. Probably it would also make sense to compile as mips32 if atomic operations are needed too. There may be other cases too. A module pass prescans the IR and adds the mips16 or nomips16 attribute to functions depending on the functions needs. Mips 16 mode can result in a 40% code compression by utililizing 16 bit encoding of many instructions. The hope is for this to replace the traditional gcc way of dealing with Mips16 code using floating point which involves essentially using soft float but with a library implemented using mips32 floating point. This gcc method also requires creating stubs so that Mips32 code can interact with these Mips 16 functions that have floating point needs. My conjecture is that in reality this traditional gcc method would never win over this new method. I will be implementing the traditional gcc method also. Some of it is already done but I needed to do the stubs to finish the work and those required this mips16/32 mixed mode capability. I have more ideas for to make this new method much better and I think the old method will just live in llvm for anyone that needs the backward compatibility but I don't for what reason that would be needed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179185 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-10 16:58:04 +00:00
#include "llvm/Support/Debug.h"
#include "llvm/Support/raw_ostream.h"
static cl::opt<std::string> Mips32FunctionMask(
"mips32-function-mask",
cl::init(""),
cl::desc("Force function to be mips32"),
cl::Hidden);
This is for an experimental option -mips-os16. The idea is to compile all Mips32 code as Mips16 unless it can't be compiled as Mips 16. For now this would happen as long as floating point instructions are not needed. Probably it would also make sense to compile as mips32 if atomic operations are needed too. There may be other cases too. A module pass prescans the IR and adds the mips16 or nomips16 attribute to functions depending on the functions needs. Mips 16 mode can result in a 40% code compression by utililizing 16 bit encoding of many instructions. The hope is for this to replace the traditional gcc way of dealing with Mips16 code using floating point which involves essentially using soft float but with a library implemented using mips32 floating point. This gcc method also requires creating stubs so that Mips32 code can interact with these Mips 16 functions that have floating point needs. My conjecture is that in reality this traditional gcc method would never win over this new method. I will be implementing the traditional gcc method also. Some of it is already done but I needed to do the stubs to finish the work and those required this mips16/32 mixed mode capability. I have more ideas for to make this new method much better and I think the old method will just live in llvm for anyone that needs the backward compatibility but I don't for what reason that would be needed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179185 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-10 16:58:04 +00:00
namespace {
// Figure out if we need float point based on the function signature.
// We need to move variables in and/or out of floating point
// registers because of the ABI
//
bool needsFPFromSig(Function &F) {
Type* RetType = F.getReturnType();
switch (RetType->getTypeID()) {
case Type::FloatTyID:
case Type::DoubleTyID:
return true;
default:
;
}
if (F.arg_size() >=1) {
Argument &Arg = F.getArgumentList().front();
switch (Arg.getType()->getTypeID()) {
case Type::FloatTyID:
case Type::DoubleTyID:
return true;
default:
;
}
}
return false;
}
// Figure out if the function will need floating point operations
//
bool needsFP(Function &F) {
if (needsFPFromSig(F))
return true;
for (Function::const_iterator BB = F.begin(), E = F.end(); BB != E; ++BB)
for (BasicBlock::const_iterator I = BB->begin(), E = BB->end();
I != E; ++I) {
const Instruction &Inst = *I;
switch (Inst.getOpcode()) {
case Instruction::FAdd:
case Instruction::FSub:
case Instruction::FMul:
case Instruction::FDiv:
case Instruction::FRem:
case Instruction::FPToUI:
case Instruction::FPToSI:
case Instruction::UIToFP:
case Instruction::SIToFP:
case Instruction::FPTrunc:
case Instruction::FPExt:
case Instruction::FCmp:
return true;
default:
;
}
if (const CallInst *CI = dyn_cast<CallInst>(I)) {
DEBUG(dbgs() << "Working on call" << "\n");
Function &F_ = *CI->getCalledFunction();
if (needsFPFromSig(F_))
return true;
}
}
return false;
}
}
namespace llvm {
bool MipsOs16::runOnModule(Module &M) {
bool usingMask = Mips32FunctionMask.length() > 0;
bool doneUsingMask = false; // this will make it stop repeating
DEBUG(dbgs() << "Run on Module MipsOs16 \n" << Mips32FunctionMask << "\n");
if (usingMask)
DEBUG(dbgs() << "using mask \n" << Mips32FunctionMask << "\n");
unsigned int functionIndex = 0;
This is for an experimental option -mips-os16. The idea is to compile all Mips32 code as Mips16 unless it can't be compiled as Mips 16. For now this would happen as long as floating point instructions are not needed. Probably it would also make sense to compile as mips32 if atomic operations are needed too. There may be other cases too. A module pass prescans the IR and adds the mips16 or nomips16 attribute to functions depending on the functions needs. Mips 16 mode can result in a 40% code compression by utililizing 16 bit encoding of many instructions. The hope is for this to replace the traditional gcc way of dealing with Mips16 code using floating point which involves essentially using soft float but with a library implemented using mips32 floating point. This gcc method also requires creating stubs so that Mips32 code can interact with these Mips 16 functions that have floating point needs. My conjecture is that in reality this traditional gcc method would never win over this new method. I will be implementing the traditional gcc method also. Some of it is already done but I needed to do the stubs to finish the work and those required this mips16/32 mixed mode capability. I have more ideas for to make this new method much better and I think the old method will just live in llvm for anyone that needs the backward compatibility but I don't for what reason that would be needed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179185 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-10 16:58:04 +00:00
bool modified = false;
for (Module::iterator F = M.begin(), E = M.end(); F != E; ++F) {
if (F->isDeclaration()) continue;
DEBUG(dbgs() << "Working on " << F->getName() << "\n");
if (usingMask) {
if (!doneUsingMask) {
if (functionIndex == Mips32FunctionMask.length())
functionIndex = 0;
switch (Mips32FunctionMask[functionIndex]) {
case '1':
DEBUG(dbgs() << "mask forced mips32: " << F->getName() << "\n");
F->addFnAttr("nomips16");
break;
case '.':
doneUsingMask = true;
break;
default:
break;
}
functionIndex++;
}
This is for an experimental option -mips-os16. The idea is to compile all Mips32 code as Mips16 unless it can't be compiled as Mips 16. For now this would happen as long as floating point instructions are not needed. Probably it would also make sense to compile as mips32 if atomic operations are needed too. There may be other cases too. A module pass prescans the IR and adds the mips16 or nomips16 attribute to functions depending on the functions needs. Mips 16 mode can result in a 40% code compression by utililizing 16 bit encoding of many instructions. The hope is for this to replace the traditional gcc way of dealing with Mips16 code using floating point which involves essentially using soft float but with a library implemented using mips32 floating point. This gcc method also requires creating stubs so that Mips32 code can interact with these Mips 16 functions that have floating point needs. My conjecture is that in reality this traditional gcc method would never win over this new method. I will be implementing the traditional gcc method also. Some of it is already done but I needed to do the stubs to finish the work and those required this mips16/32 mixed mode capability. I have more ideas for to make this new method much better and I think the old method will just live in llvm for anyone that needs the backward compatibility but I don't for what reason that would be needed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179185 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-10 16:58:04 +00:00
}
else {
if (needsFP(*F)) {
DEBUG(dbgs() << "os16 forced mips32: " << F->getName() << "\n");
F->addFnAttr("nomips16");
}
else {
DEBUG(dbgs() << "os16 forced mips16: " << F->getName() << "\n");
F->addFnAttr("mips16");
}
This is for an experimental option -mips-os16. The idea is to compile all Mips32 code as Mips16 unless it can't be compiled as Mips 16. For now this would happen as long as floating point instructions are not needed. Probably it would also make sense to compile as mips32 if atomic operations are needed too. There may be other cases too. A module pass prescans the IR and adds the mips16 or nomips16 attribute to functions depending on the functions needs. Mips 16 mode can result in a 40% code compression by utililizing 16 bit encoding of many instructions. The hope is for this to replace the traditional gcc way of dealing with Mips16 code using floating point which involves essentially using soft float but with a library implemented using mips32 floating point. This gcc method also requires creating stubs so that Mips32 code can interact with these Mips 16 functions that have floating point needs. My conjecture is that in reality this traditional gcc method would never win over this new method. I will be implementing the traditional gcc method also. Some of it is already done but I needed to do the stubs to finish the work and those required this mips16/32 mixed mode capability. I have more ideas for to make this new method much better and I think the old method will just live in llvm for anyone that needs the backward compatibility but I don't for what reason that would be needed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179185 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-10 16:58:04 +00:00
}
}
return modified;
}
char MipsOs16::ID = 0;
}
ModulePass *llvm::createMipsOs16(MipsTargetMachine &TM) {
return new MipsOs16;
}