2001-08-24 01:05:04 +08:00
|
|
|
//===-- Execution.cpp - Implement code to simulate the program ------------===//
|
2005-04-22 06:43:08 +08:00
|
|
|
//
|
2003-10-21 03:43:21 +08:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file was developed by the LLVM research group and is distributed under
|
|
|
|
// the University of Illinois Open Source License. See LICENSE.TXT for details.
|
2005-04-22 06:43:08 +08:00
|
|
|
//
|
2003-10-21 03:43:21 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2005-04-22 06:43:08 +08:00
|
|
|
//
|
2001-08-24 01:05:04 +08:00
|
|
|
// This file contains the actual instruction interpreter.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2003-12-11 08:22:59 +08:00
|
|
|
#define DEBUG_TYPE "interpreter"
|
2001-08-24 01:05:04 +08:00
|
|
|
#include "Interpreter.h"
|
2002-04-29 03:55:58 +08:00
|
|
|
#include "llvm/Constants.h"
|
2003-12-28 17:44:37 +08:00
|
|
|
#include "llvm/DerivedTypes.h"
|
|
|
|
#include "llvm/Instructions.h"
|
2004-06-20 15:49:54 +08:00
|
|
|
#include "llvm/CodeGen/IntrinsicLowering.h"
|
2003-11-26 04:44:56 +08:00
|
|
|
#include "llvm/Support/GetElementPtrTypeIterator.h"
|
2004-09-02 06:55:40 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
|
|
|
#include "llvm/Support/Debug.h"
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#include "llvm/Support/MathExtras.h"
|
2006-12-02 10:22:01 +08:00
|
|
|
#include <cmath>
|
2003-11-26 04:44:56 +08:00
|
|
|
using namespace llvm;
|
2002-12-24 07:59:41 +08:00
|
|
|
|
2006-12-20 06:56:53 +08:00
|
|
|
STATISTIC(NumDynamicInsts, "Number of dynamic instructions executed");
|
|
|
|
static Interpreter *TheEE = 0;
|
2003-11-12 06:41:34 +08:00
|
|
|
|
2003-12-28 17:44:37 +08:00
|
|
|
|
2001-10-15 21:25:40 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Value Manipulation code
|
|
|
|
//===----------------------------------------------------------------------===//
|
2003-12-28 17:44:37 +08:00
|
|
|
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeAddInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
|
|
|
static GenericValue executeSubInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
|
|
|
static GenericValue executeMulInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
2006-10-26 14:15:43 +08:00
|
|
|
static GenericValue executeUDivInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
|
|
|
static GenericValue executeSDivInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
|
|
|
static GenericValue executeFDivInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
2006-11-02 09:53:59 +08:00
|
|
|
static GenericValue executeURemInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
|
|
|
static GenericValue executeSRemInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
|
|
|
static GenericValue executeFRemInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeAndInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
|
|
|
static GenericValue executeOrInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
|
|
|
static GenericValue executeXorInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
2006-12-23 14:05:41 +08:00
|
|
|
static GenericValue executeCmpInst(unsigned predicate, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty);
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeShlInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
2006-11-08 14:47:33 +08:00
|
|
|
static GenericValue executeLShrInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
|
|
|
static GenericValue executeAShrInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty);
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeSelectInst(GenericValue Src1, GenericValue Src2,
|
2004-04-21 00:43:21 +08:00
|
|
|
GenericValue Src3);
|
|
|
|
|
2007-01-21 04:12:29 +08:00
|
|
|
inline uint64_t doSignExtension(uint64_t Val, const IntegerType* ITy) {
|
|
|
|
// Determine if the value is signed or not
|
|
|
|
bool isSigned = (Val & (1 << (ITy->getBitWidth()-1))) != 0;
|
|
|
|
// If its signed, extend the sign bits
|
|
|
|
if (isSigned)
|
|
|
|
Val |= ~ITy->getBitMask();
|
|
|
|
return Val;
|
|
|
|
}
|
|
|
|
|
2003-12-11 08:22:59 +08:00
|
|
|
GenericValue Interpreter::getConstantExprValue (ConstantExpr *CE,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
switch (CE->getOpcode()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case Instruction::Trunc:
|
|
|
|
return executeTruncInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::ZExt:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executeZExtInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::SExt:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executeSExtInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::FPTrunc:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executeFPTruncInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::FPExt:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executeFPExtInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::UIToFP:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executeUIToFPInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::SIToFP:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executeSIToFPInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::FPToUI:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executeFPToUIInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::FPToSI:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executeFPToSIInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::PtrToInt:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executePtrToIntInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::IntToPtr:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executeIntToPtrInst(CE->getOperand(0), CE->getType(), SF);
|
2006-11-27 09:05:10 +08:00
|
|
|
case Instruction::BitCast:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return executeBitCastInst(CE->getOperand(0), CE->getType(), SF);
|
2003-12-11 08:22:59 +08:00
|
|
|
case Instruction::GetElementPtr:
|
|
|
|
return executeGEPOperation(CE->getOperand(0), gep_type_begin(CE),
|
|
|
|
gep_type_end(CE), SF);
|
|
|
|
case Instruction::Add:
|
|
|
|
return executeAddInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
|
|
|
case Instruction::Sub:
|
|
|
|
return executeSubInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
|
|
|
case Instruction::Mul:
|
|
|
|
return executeMulInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
2006-10-26 14:15:43 +08:00
|
|
|
case Instruction::SDiv:
|
|
|
|
return executeSDivInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
|
|
|
case Instruction::UDiv:
|
|
|
|
return executeUDivInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
|
|
|
case Instruction::FDiv:
|
|
|
|
return executeFDivInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
2006-11-02 09:53:59 +08:00
|
|
|
case Instruction::URem:
|
|
|
|
return executeURemInst(getOperandValue(CE->getOperand(0), SF),
|
2003-12-11 08:22:59 +08:00
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
2006-11-02 09:53:59 +08:00
|
|
|
case Instruction::SRem:
|
|
|
|
return executeSRemInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
|
|
|
case Instruction::FRem:
|
|
|
|
return executeFRemInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
2003-12-11 08:22:59 +08:00
|
|
|
case Instruction::And:
|
|
|
|
return executeAndInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
|
|
|
case Instruction::Or:
|
|
|
|
return executeOrInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
|
|
|
case Instruction::Xor:
|
|
|
|
return executeXorInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
2006-12-23 14:05:41 +08:00
|
|
|
case Instruction::FCmp:
|
|
|
|
case Instruction::ICmp:
|
|
|
|
return executeCmpInst(CE->getPredicate(),
|
|
|
|
getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
2003-12-11 08:22:59 +08:00
|
|
|
case Instruction::Shl:
|
|
|
|
return executeShlInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
2006-11-08 14:47:33 +08:00
|
|
|
case Instruction::LShr:
|
|
|
|
return executeLShrInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
|
|
|
case Instruction::AShr:
|
|
|
|
return executeAShrInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
CE->getOperand(0)->getType());
|
2004-04-21 00:43:21 +08:00
|
|
|
case Instruction::Select:
|
|
|
|
return executeSelectInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
getOperandValue(CE->getOperand(2), SF));
|
2003-12-11 08:22:59 +08:00
|
|
|
default:
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "Unhandled ConstantExpr: " << *CE << "\n";
|
2003-12-11 08:22:59 +08:00
|
|
|
abort();
|
|
|
|
return GenericValue();
|
|
|
|
}
|
|
|
|
}
|
2002-08-28 06:33:45 +08:00
|
|
|
|
2003-09-06 02:55:03 +08:00
|
|
|
GenericValue Interpreter::getOperandValue(Value *V, ExecutionContext &SF) {
|
2002-08-28 06:33:45 +08:00
|
|
|
if (ConstantExpr *CE = dyn_cast<ConstantExpr>(V)) {
|
2003-12-11 08:22:59 +08:00
|
|
|
return getConstantExprValue(CE, SF);
|
2002-08-28 06:33:45 +08:00
|
|
|
} else if (Constant *CPV = dyn_cast<Constant>(V)) {
|
2003-12-11 08:22:59 +08:00
|
|
|
return getConstantValue(CPV);
|
2001-10-15 21:25:40 +08:00
|
|
|
} else if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) {
|
2003-12-11 08:22:59 +08:00
|
|
|
return PTOGV(getPointerToGlobal(GV));
|
2001-10-15 21:25:40 +08:00
|
|
|
} else {
|
2003-10-25 03:59:01 +08:00
|
|
|
return SF.Values[V];
|
2001-10-15 21:25:40 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void SetValue(Value *V, GenericValue Val, ExecutionContext &SF) {
|
2003-10-25 03:59:01 +08:00
|
|
|
SF.Values[V] = Val;
|
2001-10-15 21:25:40 +08:00
|
|
|
}
|
|
|
|
|
2001-10-15 13:51:48 +08:00
|
|
|
void Interpreter::initializeExecutionEngine() {
|
2002-12-24 07:59:41 +08:00
|
|
|
TheEE = this;
|
2001-10-15 13:51:48 +08:00
|
|
|
}
|
|
|
|
|
2001-08-24 01:05:04 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Binary Instruction Implementations
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#define IMPLEMENT_BINARY_OPERATOR(OP, TY) \
|
|
|
|
case Type::TY##TyID: Dest.TY##Val = Src1.TY##Val OP Src2.TY##Val; break
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#define IMPLEMENT_INTEGER_BINOP(OP, TY) \
|
|
|
|
case Type::IntegerTyID: { \
|
|
|
|
unsigned BitWidth = cast<IntegerType>(TY)->getBitWidth(); \
|
|
|
|
if (BitWidth == 1) \
|
|
|
|
Dest.Int1Val = Src1.Int1Val OP Src2.Int1Val; \
|
|
|
|
else if (BitWidth <= 8) \
|
|
|
|
Dest.Int8Val = Src1.Int8Val OP Src2.Int8Val; \
|
|
|
|
else if (BitWidth <= 16) \
|
|
|
|
Dest.Int16Val = Src1.Int16Val OP Src2.Int16Val; \
|
|
|
|
else if (BitWidth <= 32) \
|
|
|
|
Dest.Int32Val = Src1.Int32Val OP Src2.Int32Val; \
|
|
|
|
else if (BitWidth <= 64) \
|
|
|
|
Dest.Int64Val = Src1.Int64Val OP Src2.Int64Val; \
|
|
|
|
else \
|
|
|
|
cerr << "Integer types > 64 bits not supported: " << *Ty << "\n"; \
|
2007-01-18 10:12:51 +08:00
|
|
|
maskToBitWidth(Dest, BitWidth); \
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
break; \
|
|
|
|
}
|
|
|
|
|
|
|
|
#define IMPLEMENT_SIGNED_BINOP(OP, TY) \
|
|
|
|
if (const IntegerType *ITy = dyn_cast<IntegerType>(TY)) { \
|
|
|
|
unsigned BitWidth = ITy->getBitWidth(); \
|
|
|
|
if (BitWidth <= 8) \
|
|
|
|
Dest.Int8Val = ((int8_t)Src1.Int8Val) OP ((int8_t)Src2.Int8Val); \
|
|
|
|
else if (BitWidth <= 16) \
|
|
|
|
Dest.Int16Val = ((int16_t)Src1.Int16Val) OP ((int16_t)Src2.Int16Val); \
|
|
|
|
else if (BitWidth <= 32) \
|
|
|
|
Dest.Int32Val = ((int32_t)Src1.Int32Val) OP ((int32_t)Src2.Int32Val); \
|
|
|
|
else if (BitWidth <= 64) \
|
|
|
|
Dest.Int64Val = ((int64_t)Src1.Int64Val) OP ((int64_t)Src2.Int64Val); \
|
|
|
|
else { \
|
|
|
|
cerr << "Integer types > 64 bits not supported: " << *Ty << "\n"; \
|
|
|
|
abort(); \
|
|
|
|
} \
|
2007-01-18 10:12:51 +08:00
|
|
|
maskToBitWidth(Dest, BitWidth); \
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
} else { \
|
|
|
|
cerr << "Unhandled type for " #OP " operator: " << *Ty << "\n"; \
|
|
|
|
abort(); \
|
|
|
|
}
|
|
|
|
|
|
|
|
#define IMPLEMENT_UNSIGNED_BINOP(OP, TY) \
|
|
|
|
if (const IntegerType *ITy = dyn_cast<IntegerType>(TY)) { \
|
|
|
|
unsigned BitWidth = ITy->getBitWidth(); \
|
|
|
|
if (BitWidth <= 8) \
|
|
|
|
Dest.Int8Val = ((uint8_t)Src1.Int8Val) OP ((uint8_t)Src2.Int8Val); \
|
|
|
|
else if (BitWidth <= 16) \
|
|
|
|
Dest.Int16Val = ((uint16_t)Src1.Int16Val) OP ((uint16_t)Src2.Int16Val); \
|
|
|
|
else if (BitWidth <= 32) \
|
|
|
|
Dest.Int32Val = ((uint32_t)Src1.Int32Val) OP ((uint32_t)Src2.Int32Val); \
|
|
|
|
else if (BitWidth <= 64) \
|
|
|
|
Dest.Int64Val = ((uint64_t)Src1.Int64Val) OP ((uint64_t)Src2.Int64Val); \
|
|
|
|
else { \
|
|
|
|
cerr << "Integer types > 64 bits not supported: " << *Ty << "\n"; \
|
|
|
|
abort(); \
|
|
|
|
} \
|
2007-01-18 10:12:51 +08:00
|
|
|
maskToBitWidth(Dest, BitWidth); \
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
} else { \
|
|
|
|
cerr << "Unhandled type for " #OP " operator: " << *Ty << "\n"; \
|
|
|
|
abort(); \
|
|
|
|
}
|
|
|
|
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeAddInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
2001-08-24 01:05:04 +08:00
|
|
|
GenericValue Dest;
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_INTEGER_BINOP(+, Ty);
|
2001-08-24 01:05:04 +08:00
|
|
|
IMPLEMENT_BINARY_OPERATOR(+, Float);
|
|
|
|
IMPLEMENT_BINARY_OPERATOR(+, Double);
|
|
|
|
default:
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "Unhandled type for Add instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeSubInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
2001-08-24 01:05:04 +08:00
|
|
|
GenericValue Dest;
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_INTEGER_BINOP(-, Ty);
|
2001-08-24 01:05:04 +08:00
|
|
|
IMPLEMENT_BINARY_OPERATOR(-, Float);
|
|
|
|
IMPLEMENT_BINARY_OPERATOR(-, Double);
|
|
|
|
default:
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "Unhandled type for Sub instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeMulInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
2001-10-27 16:28:11 +08:00
|
|
|
GenericValue Dest;
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_INTEGER_BINOP(*, Ty);
|
2001-10-27 16:28:11 +08:00
|
|
|
IMPLEMENT_BINARY_OPERATOR(*, Float);
|
|
|
|
IMPLEMENT_BINARY_OPERATOR(*, Double);
|
|
|
|
default:
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "Unhandled type for Mul instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-10-27 16:28:11 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2006-10-26 14:15:43 +08:00
|
|
|
static GenericValue executeUDivInst(GenericValue Src1, GenericValue Src2,
|
2005-04-22 06:43:08 +08:00
|
|
|
const Type *Ty) {
|
2001-10-27 16:28:11 +08:00
|
|
|
GenericValue Dest;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_BINOP(/,Ty)
|
2006-10-26 14:15:43 +08:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeSDivInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_SIGNED_BINOP(/,Ty)
|
2006-10-26 14:15:43 +08:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFDivInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
2001-10-27 16:28:11 +08:00
|
|
|
IMPLEMENT_BINARY_OPERATOR(/, Float);
|
|
|
|
IMPLEMENT_BINARY_OPERATOR(/, Double);
|
|
|
|
default:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
cerr << "Unhandled type for FDiv instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-10-31 04:27:31 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2006-11-02 09:53:59 +08:00
|
|
|
static GenericValue executeURemInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_BINOP(%, Ty)
|
2006-11-02 09:53:59 +08:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeSRemInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_SIGNED_BINOP(%, Ty)
|
2006-11-02 09:53:59 +08:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFRemInst(GenericValue Src1, GenericValue Src2,
|
2005-04-22 06:43:08 +08:00
|
|
|
const Type *Ty) {
|
2001-10-31 04:27:31 +08:00
|
|
|
GenericValue Dest;
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
2001-10-31 04:27:31 +08:00
|
|
|
case Type::FloatTyID:
|
|
|
|
Dest.FloatVal = fmod(Src1.FloatVal, Src2.FloatVal);
|
|
|
|
break;
|
|
|
|
case Type::DoubleTyID:
|
|
|
|
Dest.DoubleVal = fmod(Src1.DoubleVal, Src2.DoubleVal);
|
|
|
|
break;
|
|
|
|
default:
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "Unhandled type for Rem instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-10-27 16:28:11 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeAndInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
2001-10-31 04:54:36 +08:00
|
|
|
GenericValue Dest;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_BINOP(&, Ty)
|
2001-11-08 03:46:27 +08:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeOrInst(GenericValue Src1, GenericValue Src2,
|
2003-04-23 04:37:39 +08:00
|
|
|
const Type *Ty) {
|
2001-11-08 03:46:27 +08:00
|
|
|
GenericValue Dest;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_BINOP(|, Ty)
|
2001-11-08 03:46:27 +08:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeXorInst(GenericValue Src1, GenericValue Src2,
|
2003-04-23 04:37:39 +08:00
|
|
|
const Type *Ty) {
|
2001-11-08 03:46:27 +08:00
|
|
|
GenericValue Dest;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_BINOP(^, Ty)
|
2001-10-31 04:54:36 +08:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#define IMPLEMENT_SIGNED_ICMP(OP, TY) \
|
|
|
|
case Type::IntegerTyID: { \
|
2007-01-21 04:12:29 +08:00
|
|
|
const IntegerType* ITy = cast<IntegerType>(TY); \
|
|
|
|
unsigned BitWidth = ITy->getBitWidth(); \
|
|
|
|
int64_t LHS = 0, RHS = 0; \
|
|
|
|
if (BitWidth <= 8) { \
|
|
|
|
LHS = int64_t(doSignExtension(uint64_t(Src1.Int8Val), ITy)); \
|
|
|
|
RHS = int64_t(doSignExtension(uint64_t(Src2.Int8Val), ITy)); \
|
|
|
|
} else if (BitWidth <= 16) { \
|
|
|
|
LHS = int64_t(doSignExtension(uint64_t(Src1.Int16Val), ITy)); \
|
|
|
|
RHS = int64_t(doSignExtension(uint64_t(Src2.Int16Val), ITy)); \
|
|
|
|
} else if (BitWidth <= 32) { \
|
|
|
|
LHS = int64_t(doSignExtension(uint64_t(Src1.Int32Val), ITy)); \
|
|
|
|
RHS = int64_t(doSignExtension(uint64_t(Src2.Int32Val), ITy)); \
|
|
|
|
} else if (BitWidth <= 64) { \
|
|
|
|
LHS = int64_t(doSignExtension(uint64_t(Src1.Int64Val), ITy)); \
|
|
|
|
RHS = int64_t(doSignExtension(uint64_t(Src2.Int64Val), ITy)); \
|
|
|
|
} else { \
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
cerr << "Integer types > 64 bits not supported: " << *Ty << "\n"; \
|
|
|
|
abort(); \
|
|
|
|
} \
|
2007-01-21 04:12:29 +08:00
|
|
|
Dest.Int1Val = LHS OP RHS; \
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
break; \
|
|
|
|
}
|
|
|
|
|
|
|
|
#define IMPLEMENT_UNSIGNED_ICMP(OP, TY) \
|
|
|
|
case Type::IntegerTyID: { \
|
|
|
|
unsigned BitWidth = cast<IntegerType>(TY)->getBitWidth(); \
|
|
|
|
if (BitWidth == 1) \
|
|
|
|
Dest.Int1Val = ((uint8_t)Src1.Int1Val) OP ((uint8_t)Src2.Int1Val); \
|
|
|
|
else if (BitWidth <= 8) \
|
|
|
|
Dest.Int1Val = ((uint8_t)Src1.Int8Val) OP ((uint8_t)Src2.Int8Val); \
|
|
|
|
else if (BitWidth <= 16) \
|
|
|
|
Dest.Int1Val = ((uint16_t)Src1.Int16Val) OP ((uint16_t)Src2.Int16Val); \
|
|
|
|
else if (BitWidth <= 32) \
|
|
|
|
Dest.Int1Val = ((uint32_t)Src1.Int32Val) OP ((uint32_t)Src2.Int32Val); \
|
|
|
|
else if (BitWidth <= 64) \
|
|
|
|
Dest.Int1Val = ((uint64_t)Src1.Int64Val) OP ((uint64_t)Src2.Int64Val); \
|
|
|
|
else { \
|
|
|
|
cerr << "Integer types > 64 bits not supported: " << *Ty << "\n"; \
|
|
|
|
abort(); \
|
|
|
|
} \
|
2007-01-18 10:12:51 +08:00
|
|
|
maskToBitWidth(Dest, BitWidth); \
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
break; \
|
|
|
|
}
|
2001-08-24 01:05:04 +08:00
|
|
|
|
2003-04-24 03:55:35 +08:00
|
|
|
// Handle pointers specially because they must be compared with only as much
|
|
|
|
// width as the host has. We _do not_ want to be comparing 64 bit values when
|
|
|
|
// running on a 32-bit target, otherwise the upper 32 bits might mess up
|
|
|
|
// comparisons if they contain garbage.
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#define IMPLEMENT_POINTER_ICMP(OP) \
|
2003-04-24 03:55:35 +08:00
|
|
|
case Type::PointerTyID: \
|
2007-01-12 02:21:29 +08:00
|
|
|
Dest.Int1Val = (void*)(intptr_t)Src1.PointerVal OP \
|
2003-04-24 03:55:35 +08:00
|
|
|
(void*)(intptr_t)Src2.PointerVal; break
|
|
|
|
|
2006-12-23 14:05:41 +08:00
|
|
|
static GenericValue executeICMP_EQ(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_ICMP(==, Ty);
|
|
|
|
IMPLEMENT_POINTER_ICMP(==);
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_EQ predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeICMP_NE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_ICMP(!=, Ty);
|
|
|
|
IMPLEMENT_POINTER_ICMP(!=);
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_NE predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeICMP_ULT(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_ICMP(<, Ty);
|
|
|
|
IMPLEMENT_POINTER_ICMP(<);
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_ULT predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeICMP_SLT(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_SIGNED_ICMP(<, Ty);
|
|
|
|
IMPLEMENT_POINTER_ICMP(<);
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_SLT predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeICMP_UGT(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_ICMP(>, Ty);
|
|
|
|
IMPLEMENT_POINTER_ICMP(>);
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_UGT predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeICMP_SGT(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_SIGNED_ICMP(>, Ty);
|
|
|
|
IMPLEMENT_POINTER_ICMP(>);
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_SGT predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeICMP_ULE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_ICMP(<=, Ty);
|
|
|
|
IMPLEMENT_POINTER_ICMP(<=);
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_ULE predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeICMP_SLE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_SIGNED_ICMP(<=, Ty);
|
|
|
|
IMPLEMENT_POINTER_ICMP(<=);
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_SLE predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeICMP_UGE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_UNSIGNED_ICMP(>=,Ty);
|
|
|
|
IMPLEMENT_POINTER_ICMP(>=);
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_UGE predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeICMP_SGE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
IMPLEMENT_SIGNED_ICMP(>=, Ty);
|
|
|
|
IMPLEMENT_POINTER_ICMP(>=);
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_SGE predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2006-12-31 13:51:36 +08:00
|
|
|
void Interpreter::visitICmpInst(ICmpInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
const Type *Ty = I.getOperand(0)->getType();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
|
|
|
GenericValue R; // Result
|
|
|
|
|
|
|
|
switch (I.getPredicate()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case ICmpInst::ICMP_EQ: R = executeICMP_EQ(Src1, Src2, Ty); break;
|
|
|
|
case ICmpInst::ICMP_NE: R = executeICMP_NE(Src1, Src2, Ty); break;
|
2006-12-31 13:51:36 +08:00
|
|
|
case ICmpInst::ICMP_ULT: R = executeICMP_ULT(Src1, Src2, Ty); break;
|
|
|
|
case ICmpInst::ICMP_SLT: R = executeICMP_SLT(Src1, Src2, Ty); break;
|
|
|
|
case ICmpInst::ICMP_UGT: R = executeICMP_UGT(Src1, Src2, Ty); break;
|
|
|
|
case ICmpInst::ICMP_SGT: R = executeICMP_SGT(Src1, Src2, Ty); break;
|
|
|
|
case ICmpInst::ICMP_ULE: R = executeICMP_ULE(Src1, Src2, Ty); break;
|
|
|
|
case ICmpInst::ICMP_SLE: R = executeICMP_SLE(Src1, Src2, Ty); break;
|
|
|
|
case ICmpInst::ICMP_UGE: R = executeICMP_UGE(Src1, Src2, Ty); break;
|
|
|
|
case ICmpInst::ICMP_SGE: R = executeICMP_SGE(Src1, Src2, Ty); break;
|
|
|
|
default:
|
|
|
|
cerr << "Don't know how to handle this ICmp predicate!\n-->" << I;
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
|
|
|
SetValue(&I, R, SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define IMPLEMENT_FCMP(OP, TY) \
|
2007-01-12 02:21:29 +08:00
|
|
|
case Type::TY##TyID: Dest.Int1Val = Src1.TY##Val OP Src2.TY##Val; break
|
2006-12-23 14:05:41 +08:00
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static GenericValue executeFCMP_OEQ(GenericValue Src1, GenericValue Src2,
|
2006-12-23 14:05:41 +08:00
|
|
|
const Type *Ty) {
|
2001-08-24 01:05:04 +08:00
|
|
|
GenericValue Dest;
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 13:51:36 +08:00
|
|
|
IMPLEMENT_FCMP(==, Float);
|
|
|
|
IMPLEMENT_FCMP(==, Double);
|
2001-08-24 01:05:04 +08:00
|
|
|
default:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
cerr << "Unhandled type for FCmp EQ instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static GenericValue executeFCMP_ONE(GenericValue Src1, GenericValue Src2,
|
2006-12-23 14:05:41 +08:00
|
|
|
const Type *Ty) {
|
2001-08-24 01:05:04 +08:00
|
|
|
GenericValue Dest;
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 13:51:36 +08:00
|
|
|
IMPLEMENT_FCMP(!=, Float);
|
|
|
|
IMPLEMENT_FCMP(!=, Double);
|
2001-11-08 03:46:27 +08:00
|
|
|
|
2001-08-24 01:05:04 +08:00
|
|
|
default:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
cerr << "Unhandled type for FCmp NE instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static GenericValue executeFCMP_OLE(GenericValue Src1, GenericValue Src2,
|
2006-12-23 14:05:41 +08:00
|
|
|
const Type *Ty) {
|
2001-08-24 01:05:04 +08:00
|
|
|
GenericValue Dest;
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 13:51:36 +08:00
|
|
|
IMPLEMENT_FCMP(<=, Float);
|
|
|
|
IMPLEMENT_FCMP(<=, Double);
|
2001-08-24 01:05:04 +08:00
|
|
|
default:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
cerr << "Unhandled type for FCmp LE instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static GenericValue executeFCMP_OGE(GenericValue Src1, GenericValue Src2,
|
2006-12-23 14:05:41 +08:00
|
|
|
const Type *Ty) {
|
2001-08-24 01:05:04 +08:00
|
|
|
GenericValue Dest;
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 13:51:36 +08:00
|
|
|
IMPLEMENT_FCMP(>=, Float);
|
|
|
|
IMPLEMENT_FCMP(>=, Double);
|
2001-08-24 01:05:04 +08:00
|
|
|
default:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
cerr << "Unhandled type for FCmp GE instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static GenericValue executeFCMP_OLT(GenericValue Src1, GenericValue Src2,
|
2006-12-23 14:05:41 +08:00
|
|
|
const Type *Ty) {
|
2001-08-24 01:05:04 +08:00
|
|
|
GenericValue Dest;
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 13:51:36 +08:00
|
|
|
IMPLEMENT_FCMP(<, Float);
|
|
|
|
IMPLEMENT_FCMP(<, Double);
|
2001-08-24 01:05:04 +08:00
|
|
|
default:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
cerr << "Unhandled type for FCmp LT instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static GenericValue executeFCMP_OGT(GenericValue Src1, GenericValue Src2,
|
2005-04-22 06:43:08 +08:00
|
|
|
const Type *Ty) {
|
2001-08-24 01:05:04 +08:00
|
|
|
GenericValue Dest;
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 13:51:36 +08:00
|
|
|
IMPLEMENT_FCMP(>, Float);
|
|
|
|
IMPLEMENT_FCMP(>, Double);
|
2001-08-24 01:05:04 +08:00
|
|
|
default:
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
cerr << "Unhandled type for FCmp GT instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#define IMPLEMENT_UNORDERED(TY, X,Y) \
|
|
|
|
if (TY == Type::FloatTy) \
|
|
|
|
if (X.FloatVal != X.FloatVal || Y.FloatVal != Y.FloatVal) { \
|
|
|
|
Dest.Int1Val = true; \
|
|
|
|
return Dest; \
|
|
|
|
} \
|
|
|
|
else if (X.DoubleVal != X.DoubleVal || Y.DoubleVal != Y.DoubleVal) { \
|
|
|
|
Dest.Int1Val = true; \
|
|
|
|
return Dest; \
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UEQ(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_OEQ(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UNE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_ONE(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_ULE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_OLE(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UGE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_OGE(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_ULT(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_OLT(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UGT(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_OGT(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_ORD(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
if (Ty == Type::FloatTy)
|
|
|
|
Dest.Int1Val = (Src1.FloatVal == Src1.FloatVal &&
|
|
|
|
Src2.FloatVal == Src2.FloatVal);
|
|
|
|
else
|
|
|
|
Dest.Int1Val = (Src1.DoubleVal == Src1.DoubleVal &&
|
|
|
|
Src2.DoubleVal == Src2.DoubleVal);
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UNO(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
if (Ty == Type::FloatTy)
|
|
|
|
Dest.Int1Val = (Src1.FloatVal != Src1.FloatVal ||
|
|
|
|
Src2.FloatVal != Src2.FloatVal);
|
|
|
|
else
|
|
|
|
Dest.Int1Val = (Src1.DoubleVal != Src1.DoubleVal ||
|
|
|
|
Src2.DoubleVal != Src2.DoubleVal);
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2006-12-23 14:05:41 +08:00
|
|
|
void Interpreter::visitFCmpInst(FCmpInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
const Type *Ty = I.getOperand(0)->getType();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
|
|
|
GenericValue R; // Result
|
|
|
|
|
|
|
|
switch (I.getPredicate()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case FCmpInst::FCMP_FALSE: R.Int1Val = false; break;
|
|
|
|
case FCmpInst::FCMP_TRUE: R.Int1Val = true; break;
|
|
|
|
case FCmpInst::FCMP_ORD: R = executeFCMP_ORD(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_UNO: R = executeFCMP_UNO(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_UEQ: R = executeFCMP_UEQ(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_OEQ: R = executeFCMP_OEQ(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_UNE: R = executeFCMP_UNE(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_ONE: R = executeFCMP_ONE(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_ULT: R = executeFCMP_ULT(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_OLT: R = executeFCMP_OLT(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_UGT: R = executeFCMP_UGT(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_OGT: R = executeFCMP_OGT(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_ULE: R = executeFCMP_ULE(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_OLE: R = executeFCMP_OLE(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_UGE: R = executeFCMP_UGE(Src1, Src2, Ty); break;
|
|
|
|
case FCmpInst::FCMP_OGE: R = executeFCMP_OGE(Src1, Src2, Ty); break;
|
2006-12-23 14:05:41 +08:00
|
|
|
default:
|
|
|
|
cerr << "Don't know how to handle this FCmp predicate!\n-->" << I;
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
|
|
|
SetValue(&I, R, SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeCmpInst(unsigned predicate, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
|
|
|
GenericValue Result;
|
|
|
|
switch (predicate) {
|
|
|
|
case ICmpInst::ICMP_EQ: return executeICMP_EQ(Src1, Src2, Ty);
|
|
|
|
case ICmpInst::ICMP_NE: return executeICMP_NE(Src1, Src2, Ty);
|
|
|
|
case ICmpInst::ICMP_UGT: return executeICMP_UGT(Src1, Src2, Ty);
|
|
|
|
case ICmpInst::ICMP_SGT: return executeICMP_SGT(Src1, Src2, Ty);
|
|
|
|
case ICmpInst::ICMP_ULT: return executeICMP_ULT(Src1, Src2, Ty);
|
|
|
|
case ICmpInst::ICMP_SLT: return executeICMP_SLT(Src1, Src2, Ty);
|
|
|
|
case ICmpInst::ICMP_UGE: return executeICMP_UGE(Src1, Src2, Ty);
|
|
|
|
case ICmpInst::ICMP_SGE: return executeICMP_SGE(Src1, Src2, Ty);
|
|
|
|
case ICmpInst::ICMP_ULE: return executeICMP_ULE(Src1, Src2, Ty);
|
|
|
|
case ICmpInst::ICMP_SLE: return executeICMP_SLE(Src1, Src2, Ty);
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case FCmpInst::FCMP_ORD: return executeFCMP_ORD(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_UNO: return executeFCMP_UNO(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_OEQ: return executeFCMP_OEQ(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_UEQ: return executeFCMP_UEQ(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_ONE: return executeFCMP_ONE(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_UNE: return executeFCMP_UNE(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_OLT: return executeFCMP_OLT(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_ULT: return executeFCMP_ULT(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_OGT: return executeFCMP_OGT(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_UGT: return executeFCMP_UGT(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_OLE: return executeFCMP_OLE(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_ULE: return executeFCMP_ULE(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_OGE: return executeFCMP_OGE(Src1, Src2, Ty);
|
|
|
|
case FCmpInst::FCMP_UGE: return executeFCMP_UGE(Src1, Src2, Ty);
|
2006-12-23 14:05:41 +08:00
|
|
|
case FCmpInst::FCMP_FALSE: {
|
|
|
|
GenericValue Result;
|
2007-01-12 02:21:29 +08:00
|
|
|
Result.Int1Val = false;
|
2006-12-23 14:05:41 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
case FCmpInst::FCMP_TRUE: {
|
|
|
|
GenericValue Result;
|
2007-01-12 02:21:29 +08:00
|
|
|
Result.Int1Val = true;
|
2006-12-23 14:05:41 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
cerr << "Unhandled Cmp predicate\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-05-11 05:22:39 +08:00
|
|
|
void Interpreter::visitBinaryOperator(BinaryOperator &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2002-06-26 00:13:21 +08:00
|
|
|
const Type *Ty = I.getOperand(0)->getType();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
2001-08-24 01:05:04 +08:00
|
|
|
GenericValue R; // Result
|
|
|
|
|
2002-06-26 00:13:21 +08:00
|
|
|
switch (I.getOpcode()) {
|
2003-04-23 04:37:39 +08:00
|
|
|
case Instruction::Add: R = executeAddInst (Src1, Src2, Ty); break;
|
|
|
|
case Instruction::Sub: R = executeSubInst (Src1, Src2, Ty); break;
|
|
|
|
case Instruction::Mul: R = executeMulInst (Src1, Src2, Ty); break;
|
2006-10-26 14:15:43 +08:00
|
|
|
case Instruction::UDiv: R = executeUDivInst (Src1, Src2, Ty); break;
|
|
|
|
case Instruction::SDiv: R = executeSDivInst (Src1, Src2, Ty); break;
|
|
|
|
case Instruction::FDiv: R = executeFDivInst (Src1, Src2, Ty); break;
|
2006-11-02 09:53:59 +08:00
|
|
|
case Instruction::URem: R = executeURemInst (Src1, Src2, Ty); break;
|
|
|
|
case Instruction::SRem: R = executeSRemInst (Src1, Src2, Ty); break;
|
|
|
|
case Instruction::FRem: R = executeFRemInst (Src1, Src2, Ty); break;
|
2003-04-23 04:37:39 +08:00
|
|
|
case Instruction::And: R = executeAndInst (Src1, Src2, Ty); break;
|
|
|
|
case Instruction::Or: R = executeOrInst (Src1, Src2, Ty); break;
|
|
|
|
case Instruction::Xor: R = executeXorInst (Src1, Src2, Ty); break;
|
2001-08-24 01:05:04 +08:00
|
|
|
default:
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "Don't know how to handle this binary operator!\n-->" << I;
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
|
2002-06-26 00:13:21 +08:00
|
|
|
SetValue(&I, R, SF);
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
|
2005-04-22 06:43:08 +08:00
|
|
|
static GenericValue executeSelectInst(GenericValue Src1, GenericValue Src2,
|
2004-04-21 00:43:21 +08:00
|
|
|
GenericValue Src3) {
|
2007-01-12 02:21:29 +08:00
|
|
|
return Src1.Int1Val ? Src2 : Src3;
|
2004-04-21 00:43:21 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitSelectInst(SelectInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
|
|
|
GenericValue Src3 = getOperandValue(I.getOperand(2), SF);
|
|
|
|
GenericValue R = executeSelectInst(Src1, Src2, Src3);
|
|
|
|
SetValue(&I, R, SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2001-08-24 01:05:04 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Terminator Instruction Implementations
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2001-10-27 12:15:57 +08:00
|
|
|
void Interpreter::exitCalled(GenericValue GV) {
|
2004-02-13 13:48:00 +08:00
|
|
|
// runAtExitHandlers() assumes there are no stack frames, but
|
|
|
|
// if exit() was called, then it had a stack frame. Blow away
|
|
|
|
// the stack before interpreting atexit handlers.
|
|
|
|
ECStack.clear ();
|
2003-12-11 08:22:59 +08:00
|
|
|
runAtExitHandlers ();
|
2006-12-31 13:51:36 +08:00
|
|
|
exit (GV.Int32Val);
|
2001-10-27 12:15:57 +08:00
|
|
|
}
|
|
|
|
|
2003-11-07 13:22:49 +08:00
|
|
|
/// Pop the last stack frame off of ECStack and then copy the result
|
|
|
|
/// back into the result variable if we are not returning void. The
|
2006-02-07 13:29:44 +08:00
|
|
|
/// result variable may be the ExitValue, or the Value of the calling
|
2003-11-08 04:44:58 +08:00
|
|
|
/// CallInst if there was a previous stack frame. This method may
|
|
|
|
/// invalidate any ECStack iterators you have. This method also takes
|
|
|
|
/// care of switching to the normal destination BB, if we are returning
|
|
|
|
/// from an invoke.
|
2003-11-07 13:22:49 +08:00
|
|
|
///
|
|
|
|
void Interpreter::popStackAndReturnValueToCaller (const Type *RetTy,
|
|
|
|
GenericValue Result) {
|
|
|
|
// Pop the current stack frame.
|
|
|
|
ECStack.pop_back();
|
|
|
|
|
2005-04-22 06:43:08 +08:00
|
|
|
if (ECStack.empty()) { // Finished main. Put result into exit code...
|
2007-01-15 10:27:26 +08:00
|
|
|
if (RetTy && RetTy->isInteger()) { // Nonvoid return type?
|
2006-02-07 13:29:44 +08:00
|
|
|
ExitValue = Result; // Capture the exit value of the program
|
2005-04-22 06:43:08 +08:00
|
|
|
} else {
|
2006-02-07 13:29:44 +08:00
|
|
|
memset(&ExitValue, 0, sizeof(ExitValue));
|
2005-04-22 06:43:08 +08:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// If we have a previous stack frame, and we have a previous call,
|
|
|
|
// fill in the return value...
|
2003-11-07 13:22:49 +08:00
|
|
|
ExecutionContext &CallingSF = ECStack.back();
|
2003-11-08 04:44:58 +08:00
|
|
|
if (Instruction *I = CallingSF.Caller.getInstruction()) {
|
2003-11-08 03:26:23 +08:00
|
|
|
if (CallingSF.Caller.getType() != Type::VoidTy) // Save result...
|
2003-11-08 04:44:58 +08:00
|
|
|
SetValue(I, Result, CallingSF);
|
|
|
|
if (InvokeInst *II = dyn_cast<InvokeInst> (I))
|
|
|
|
SwitchToNewBasicBlock (II->getNormalDest (), CallingSF);
|
2003-11-08 03:26:23 +08:00
|
|
|
CallingSF.Caller = CallSite(); // We returned from the call...
|
2003-11-07 13:22:49 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-05-11 05:22:39 +08:00
|
|
|
void Interpreter::visitReturnInst(ReturnInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2003-11-07 13:22:49 +08:00
|
|
|
const Type *RetTy = Type::VoidTy;
|
2001-08-24 01:05:04 +08:00
|
|
|
GenericValue Result;
|
|
|
|
|
|
|
|
// Save away the return value... (if we are not 'ret void')
|
2002-06-26 00:13:21 +08:00
|
|
|
if (I.getNumOperands()) {
|
|
|
|
RetTy = I.getReturnValue()->getType();
|
|
|
|
Result = getOperandValue(I.getReturnValue(), SF);
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
|
2003-11-07 13:22:49 +08:00
|
|
|
popStackAndReturnValueToCaller(RetTy, Result);
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
|
2003-11-08 04:07:06 +08:00
|
|
|
void Interpreter::visitUnwindInst(UnwindInst &I) {
|
2003-11-08 04:44:58 +08:00
|
|
|
// Unwind stack
|
|
|
|
Instruction *Inst;
|
|
|
|
do {
|
|
|
|
ECStack.pop_back ();
|
|
|
|
if (ECStack.empty ())
|
|
|
|
abort ();
|
|
|
|
Inst = ECStack.back ().Caller.getInstruction ();
|
|
|
|
} while (!(Inst && isa<InvokeInst> (Inst)));
|
|
|
|
|
|
|
|
// Return from invoke
|
|
|
|
ExecutionContext &InvokingSF = ECStack.back ();
|
|
|
|
InvokingSF.Caller = CallSite ();
|
|
|
|
|
|
|
|
// Go to exceptional destination BB of invoke instruction
|
2004-02-09 05:44:31 +08:00
|
|
|
SwitchToNewBasicBlock(cast<InvokeInst>(Inst)->getUnwindDest(), InvokingSF);
|
2003-11-08 04:07:06 +08:00
|
|
|
}
|
|
|
|
|
2004-10-17 02:21:33 +08:00
|
|
|
void Interpreter::visitUnreachableInst(UnreachableInst &I) {
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "ERROR: Program executed an 'unreachable' instruction!\n";
|
2004-10-17 02:21:33 +08:00
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
2003-05-11 05:22:39 +08:00
|
|
|
void Interpreter::visitBranchInst(BranchInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2001-08-24 01:05:04 +08:00
|
|
|
BasicBlock *Dest;
|
|
|
|
|
2002-06-26 00:13:21 +08:00
|
|
|
Dest = I.getSuccessor(0); // Uncond branches have a fixed dest...
|
|
|
|
if (!I.isUnconditional()) {
|
|
|
|
Value *Cond = I.getCondition();
|
2007-01-12 02:21:29 +08:00
|
|
|
if (getOperandValue(Cond, SF).Int1Val == 0) // If false cond...
|
2005-04-22 06:43:08 +08:00
|
|
|
Dest = I.getSuccessor(1);
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
2003-05-11 04:21:16 +08:00
|
|
|
SwitchToNewBasicBlock(Dest, SF);
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
|
2003-05-11 05:22:39 +08:00
|
|
|
void Interpreter::visitSwitchInst(SwitchInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2003-04-23 04:34:47 +08:00
|
|
|
GenericValue CondVal = getOperandValue(I.getOperand(0), SF);
|
|
|
|
const Type *ElTy = I.getOperand(0)->getType();
|
|
|
|
|
|
|
|
// Check to see if any of the cases match...
|
2003-05-11 04:21:16 +08:00
|
|
|
BasicBlock *Dest = 0;
|
|
|
|
for (unsigned i = 2, e = I.getNumOperands(); i != e; i += 2)
|
2006-12-23 14:05:41 +08:00
|
|
|
if (executeICMP_EQ(CondVal,
|
2007-01-12 02:21:29 +08:00
|
|
|
getOperandValue(I.getOperand(i), SF), ElTy).Int1Val) {
|
2003-04-23 04:34:47 +08:00
|
|
|
Dest = cast<BasicBlock>(I.getOperand(i+1));
|
|
|
|
break;
|
|
|
|
}
|
2005-04-22 06:43:08 +08:00
|
|
|
|
2003-04-23 04:34:47 +08:00
|
|
|
if (!Dest) Dest = I.getDefaultDest(); // No cases matched: use default
|
2003-05-11 04:21:16 +08:00
|
|
|
SwitchToNewBasicBlock(Dest, SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
// SwitchToNewBasicBlock - This method is used to jump to a new basic block.
|
|
|
|
// This function handles the actual updating of block and instruction iterators
|
|
|
|
// as well as execution of all of the PHI nodes in the destination block.
|
|
|
|
//
|
|
|
|
// This method does this because all of the PHI nodes must be executed
|
|
|
|
// atomically, reading their inputs before any of the results are updated. Not
|
|
|
|
// doing this can cause problems if the PHI nodes depend on other PHI nodes for
|
|
|
|
// their inputs. If the input PHI node is updated before it is read, incorrect
|
|
|
|
// results can happen. Thus we use a two phase approach.
|
|
|
|
//
|
|
|
|
void Interpreter::SwitchToNewBasicBlock(BasicBlock *Dest, ExecutionContext &SF){
|
|
|
|
BasicBlock *PrevBB = SF.CurBB; // Remember where we came from...
|
|
|
|
SF.CurBB = Dest; // Update CurBB to branch destination
|
|
|
|
SF.CurInst = SF.CurBB->begin(); // Update new instruction ptr...
|
|
|
|
|
|
|
|
if (!isa<PHINode>(SF.CurInst)) return; // Nothing fancy to do
|
|
|
|
|
|
|
|
// Loop over all of the PHI nodes in the current block, reading their inputs.
|
|
|
|
std::vector<GenericValue> ResultValues;
|
|
|
|
|
|
|
|
for (; PHINode *PN = dyn_cast<PHINode>(SF.CurInst); ++SF.CurInst) {
|
|
|
|
// Search for the value corresponding to this previous bb...
|
|
|
|
int i = PN->getBasicBlockIndex(PrevBB);
|
|
|
|
assert(i != -1 && "PHINode doesn't contain entry for predecessor??");
|
|
|
|
Value *IncomingValue = PN->getIncomingValue(i);
|
2005-04-22 06:43:08 +08:00
|
|
|
|
2003-05-11 04:21:16 +08:00
|
|
|
// Save the incoming value for this PHI node...
|
|
|
|
ResultValues.push_back(getOperandValue(IncomingValue, SF));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now loop over all of the PHI nodes setting their values...
|
|
|
|
SF.CurInst = SF.CurBB->begin();
|
2004-09-16 01:06:42 +08:00
|
|
|
for (unsigned i = 0; isa<PHINode>(SF.CurInst); ++SF.CurInst, ++i) {
|
|
|
|
PHINode *PN = cast<PHINode>(SF.CurInst);
|
2003-05-11 04:21:16 +08:00
|
|
|
SetValue(PN, ResultValues[i], SF);
|
2004-09-16 01:06:42 +08:00
|
|
|
}
|
2003-04-23 04:34:47 +08:00
|
|
|
}
|
|
|
|
|
2001-08-27 13:16:50 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Memory Instruction Implementations
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2003-05-11 05:22:39 +08:00
|
|
|
void Interpreter::visitAllocationInst(AllocationInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
|
2002-06-26 00:13:21 +08:00
|
|
|
const Type *Ty = I.getType()->getElementType(); // Type to be allocated
|
2001-08-27 13:16:50 +08:00
|
|
|
|
2002-04-29 05:57:33 +08:00
|
|
|
// Get the number of elements being allocated by the array...
|
2006-12-31 13:51:36 +08:00
|
|
|
unsigned NumElements = getOperandValue(I.getOperand(0), SF).Int32Val;
|
2001-08-27 13:16:50 +08:00
|
|
|
|
|
|
|
// Allocate enough memory to hold the type...
|
2005-01-09 04:05:34 +08:00
|
|
|
void *Memory = malloc(NumElements * (size_t)TD.getTypeSize(Ty));
|
2002-02-20 02:50:09 +08:00
|
|
|
|
2002-12-24 07:59:41 +08:00
|
|
|
GenericValue Result = PTOGV(Memory);
|
2001-11-08 03:46:27 +08:00
|
|
|
assert(Result.PointerVal != 0 && "Null pointer returned by malloc!");
|
2002-06-26 00:13:21 +08:00
|
|
|
SetValue(&I, Result, SF);
|
2001-08-27 13:16:50 +08:00
|
|
|
|
2002-06-26 00:13:21 +08:00
|
|
|
if (I.getOpcode() == Instruction::Alloca)
|
2002-02-20 02:50:09 +08:00
|
|
|
ECStack.back().Allocas.add(Memory);
|
2001-08-27 13:16:50 +08:00
|
|
|
}
|
|
|
|
|
2003-05-11 05:22:39 +08:00
|
|
|
void Interpreter::visitFreeInst(FreeInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2002-06-26 00:13:21 +08:00
|
|
|
assert(isa<PointerType>(I.getOperand(0)->getType()) && "Freeing nonptr?");
|
|
|
|
GenericValue Value = getOperandValue(I.getOperand(0), SF);
|
2001-08-27 13:16:50 +08:00
|
|
|
// TODO: Check to make sure memory is allocated
|
2002-12-24 07:59:41 +08:00
|
|
|
free(GVTOP(Value)); // Free memory
|
2001-08-27 13:16:50 +08:00
|
|
|
}
|
|
|
|
|
2002-08-28 06:33:45 +08:00
|
|
|
// getElementOffset - The workhorse for getelementptr.
|
2001-10-30 03:32:19 +08:00
|
|
|
//
|
2003-11-26 04:44:56 +08:00
|
|
|
GenericValue Interpreter::executeGEPOperation(Value *Ptr, gep_type_iterator I,
|
2005-04-22 06:43:08 +08:00
|
|
|
gep_type_iterator E,
|
|
|
|
ExecutionContext &SF) {
|
2002-08-28 06:33:45 +08:00
|
|
|
assert(isa<PointerType>(Ptr->getType()) &&
|
2001-10-30 03:32:19 +08:00
|
|
|
"Cannot getElementOffset of a nonpointer type!");
|
|
|
|
|
2001-11-08 03:46:27 +08:00
|
|
|
PointerTy Total = 0;
|
2002-08-28 06:33:45 +08:00
|
|
|
|
|
|
|
for (; I != E; ++I) {
|
2003-11-26 04:44:56 +08:00
|
|
|
if (const StructType *STy = dyn_cast<StructType>(*I)) {
|
2001-11-27 02:18:18 +08:00
|
|
|
const StructLayout *SLO = TD.getStructLayout(STy);
|
2005-04-22 06:43:08 +08:00
|
|
|
|
2006-10-20 15:07:24 +08:00
|
|
|
const ConstantInt *CPU = cast<ConstantInt>(I.getOperand());
|
|
|
|
unsigned Index = unsigned(CPU->getZExtValue());
|
2005-04-22 06:43:08 +08:00
|
|
|
|
2005-01-09 04:05:34 +08:00
|
|
|
Total += (PointerTy)SLO->MemberOffsets[Index];
|
2003-11-26 04:44:56 +08:00
|
|
|
} else {
|
|
|
|
const SequentialType *ST = cast<SequentialType>(*I);
|
2003-02-26 05:14:59 +08:00
|
|
|
// Get the index number for the array... which must be long type...
|
2003-11-26 04:44:56 +08:00
|
|
|
GenericValue IdxGV = getOperandValue(I.getOperand(), SF);
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
int64_t Idx;
|
|
|
|
unsigned BitWidth =
|
|
|
|
cast<IntegerType>(I.getOperand()->getType())->getBitWidth();
|
2007-01-18 09:25:42 +08:00
|
|
|
if (BitWidth == 32)
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
Idx = (int64_t)(int32_t)IdxGV.Int32Val;
|
2007-01-18 09:25:42 +08:00
|
|
|
else if (BitWidth == 64)
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
Idx = (int64_t)IdxGV.Int64Val;
|
|
|
|
else
|
2007-01-18 09:25:42 +08:00
|
|
|
assert(0 && "Invalid index type for getelementptr");
|
2005-01-09 04:05:34 +08:00
|
|
|
Total += PointerTy(TD.getTypeSize(ST->getElementType())*Idx);
|
2003-10-25 03:59:01 +08:00
|
|
|
}
|
2001-10-30 03:32:19 +08:00
|
|
|
}
|
|
|
|
|
2002-08-28 06:33:45 +08:00
|
|
|
GenericValue Result;
|
|
|
|
Result.PointerVal = getOperandValue(Ptr, SF).PointerVal + Total;
|
|
|
|
return Result;
|
2001-10-30 03:32:19 +08:00
|
|
|
}
|
|
|
|
|
2003-05-11 05:22:39 +08:00
|
|
|
void Interpreter::visitGetElementPtrInst(GetElementPtrInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2002-12-24 07:59:41 +08:00
|
|
|
SetValue(&I, TheEE->executeGEPOperation(I.getPointerOperand(),
|
2003-11-26 04:44:56 +08:00
|
|
|
gep_type_begin(I), gep_type_end(I), SF), SF);
|
2001-10-30 03:32:19 +08:00
|
|
|
}
|
|
|
|
|
2003-05-11 05:22:39 +08:00
|
|
|
void Interpreter::visitLoadInst(LoadInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2002-06-26 00:13:21 +08:00
|
|
|
GenericValue SRC = getOperandValue(I.getPointerOperand(), SF);
|
2002-12-24 07:59:41 +08:00
|
|
|
GenericValue *Ptr = (GenericValue*)GVTOP(SRC);
|
2003-05-09 00:52:43 +08:00
|
|
|
GenericValue Result = LoadValueFromMemory(Ptr, I.getType());
|
2002-06-26 00:13:21 +08:00
|
|
|
SetValue(&I, Result, SF);
|
2001-08-27 13:16:50 +08:00
|
|
|
}
|
|
|
|
|
2003-05-11 05:22:39 +08:00
|
|
|
void Interpreter::visitStoreInst(StoreInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2002-06-26 00:13:21 +08:00
|
|
|
GenericValue Val = getOperandValue(I.getOperand(0), SF);
|
2002-10-16 04:34:05 +08:00
|
|
|
GenericValue SRC = getOperandValue(I.getPointerOperand(), SF);
|
2002-12-24 07:59:41 +08:00
|
|
|
StoreValueToMemory(Val, (GenericValue *)GVTOP(SRC),
|
2002-10-26 09:57:15 +08:00
|
|
|
I.getOperand(0)->getType());
|
2001-08-27 13:16:50 +08:00
|
|
|
}
|
|
|
|
|
2001-08-24 01:05:04 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Miscellaneous Instruction Implementations
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2003-11-08 04:04:22 +08:00
|
|
|
void Interpreter::visitCallSite(CallSite CS) {
|
2003-05-11 05:22:39 +08:00
|
|
|
ExecutionContext &SF = ECStack.back();
|
2003-12-28 17:44:37 +08:00
|
|
|
|
|
|
|
// Check to see if this is an intrinsic function call...
|
|
|
|
if (Function *F = CS.getCalledFunction())
|
2004-01-14 14:02:53 +08:00
|
|
|
if (F->isExternal ())
|
2003-12-28 17:44:37 +08:00
|
|
|
switch (F->getIntrinsicID()) {
|
2004-01-14 14:02:53 +08:00
|
|
|
case Intrinsic::not_intrinsic:
|
|
|
|
break;
|
2004-03-13 08:24:00 +08:00
|
|
|
case Intrinsic::vastart: { // va_start
|
2004-02-26 07:01:48 +08:00
|
|
|
GenericValue ArgIndex;
|
|
|
|
ArgIndex.UIntPairVal.first = ECStack.size() - 1;
|
|
|
|
ArgIndex.UIntPairVal.second = 0;
|
|
|
|
SetValue(CS.getInstruction(), ArgIndex, SF);
|
2003-12-28 17:44:37 +08:00
|
|
|
return;
|
2004-02-26 07:01:48 +08:00
|
|
|
}
|
2004-03-13 08:24:00 +08:00
|
|
|
case Intrinsic::vaend: // va_end is a noop for the interpreter
|
2003-12-28 17:44:37 +08:00
|
|
|
return;
|
2004-03-13 08:24:00 +08:00
|
|
|
case Intrinsic::vacopy: // va_copy: dest = src
|
2003-12-28 17:44:37 +08:00
|
|
|
SetValue(CS.getInstruction(), getOperandValue(*CS.arg_begin(), SF), SF);
|
|
|
|
return;
|
|
|
|
default:
|
2004-01-14 14:02:53 +08:00
|
|
|
// If it is an unknown intrinsic function, use the intrinsic lowering
|
2003-12-28 17:44:37 +08:00
|
|
|
// class to transform it into hopefully tasty LLVM code.
|
|
|
|
//
|
|
|
|
Instruction *Prev = CS.getInstruction()->getPrev();
|
|
|
|
BasicBlock *Parent = CS.getInstruction()->getParent();
|
|
|
|
IL->LowerIntrinsicCall(cast<CallInst>(CS.getInstruction()));
|
|
|
|
|
|
|
|
// Restore the CurInst pointer to the first instruction newly inserted, if
|
|
|
|
// any.
|
|
|
|
if (!Prev) {
|
|
|
|
SF.CurInst = Parent->begin();
|
|
|
|
} else {
|
|
|
|
SF.CurInst = Prev;
|
|
|
|
++SF.CurInst;
|
|
|
|
}
|
2004-04-24 02:05:28 +08:00
|
|
|
return;
|
2003-12-28 17:44:37 +08:00
|
|
|
}
|
|
|
|
|
2003-11-08 04:04:22 +08:00
|
|
|
SF.Caller = CS;
|
2003-04-23 05:22:33 +08:00
|
|
|
std::vector<GenericValue> ArgVals;
|
2003-11-08 03:59:08 +08:00
|
|
|
const unsigned NumArgs = SF.Caller.arg_size();
|
|
|
|
ArgVals.reserve(NumArgs);
|
|
|
|
for (CallSite::arg_iterator i = SF.Caller.arg_begin(),
|
|
|
|
e = SF.Caller.arg_end(); i != e; ++i) {
|
|
|
|
Value *V = *i;
|
|
|
|
ArgVals.push_back(getOperandValue(V, SF));
|
2003-01-13 08:58:52 +08:00
|
|
|
// Promote all integral types whose size is < sizeof(int) into ints. We do
|
|
|
|
// this by zero or sign extending the value as appropriate according to the
|
|
|
|
// source type.
|
2003-11-08 03:59:08 +08:00
|
|
|
const Type *Ty = V->getType();
|
2007-01-15 10:27:26 +08:00
|
|
|
if (Ty->isInteger()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
if (Ty->getPrimitiveSizeInBits() == 1)
|
2007-01-12 02:21:29 +08:00
|
|
|
ArgVals.back().Int32Val = ArgVals.back().Int1Val;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
else if (Ty->getPrimitiveSizeInBits() <= 8)
|
|
|
|
ArgVals.back().Int32Val = ArgVals.back().Int8Val;
|
|
|
|
else if (Ty->getPrimitiveSizeInBits() <= 16)
|
|
|
|
ArgVals.back().Int32Val = ArgVals.back().Int16Val;
|
2003-01-13 08:58:52 +08:00
|
|
|
}
|
|
|
|
}
|
2001-09-10 12:49:44 +08:00
|
|
|
|
2005-04-22 06:43:08 +08:00
|
|
|
// To handle indirect calls, we must get the pointer value from the argument
|
2002-04-08 04:49:59 +08:00
|
|
|
// and treat it as a function pointer.
|
2005-04-22 06:43:08 +08:00
|
|
|
GenericValue SRC = getOperandValue(SF.Caller.getCalledValue(), SF);
|
2003-05-09 00:18:31 +08:00
|
|
|
callFunction((Function*)GVTOP(SRC), ArgVals);
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
|
2003-12-11 08:22:59 +08:00
|
|
|
static GenericValue executeShlInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
2001-08-27 13:16:50 +08:00
|
|
|
GenericValue Dest;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
if (const IntegerType *ITy = cast<IntegerType>(Ty)) {
|
|
|
|
unsigned BitWidth = ITy->getBitWidth();
|
2007-01-18 10:12:51 +08:00
|
|
|
if (BitWidth <= 8)
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
Dest.Int8Val = ((uint8_t)Src1.Int8Val) << ((uint32_t)Src2.Int8Val);
|
2007-01-18 10:12:51 +08:00
|
|
|
else if (BitWidth <= 16)
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
Dest.Int16Val = ((uint16_t)Src1.Int16Val) << ((uint32_t)Src2.Int8Val);
|
2007-01-18 10:12:51 +08:00
|
|
|
else if (BitWidth <= 32)
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
Dest.Int32Val = ((uint32_t)Src1.Int32Val) << ((uint32_t)Src2.Int8Val);
|
2007-01-18 10:12:51 +08:00
|
|
|
else if (BitWidth <= 64)
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
Dest.Int64Val = ((uint64_t)Src1.Int64Val) << ((uint32_t)Src2.Int8Val);
|
2007-01-18 10:12:51 +08:00
|
|
|
else {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
cerr << "Integer types > 64 bits not supported: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
2007-01-18 10:12:51 +08:00
|
|
|
maskToBitWidth(Dest, BitWidth);
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
} else {
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "Unhandled type for Shl instruction: " << *Ty << "\n";
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
abort();
|
2001-08-27 13:16:50 +08:00
|
|
|
}
|
2003-12-11 08:22:59 +08:00
|
|
|
return Dest;
|
2001-08-27 13:16:50 +08:00
|
|
|
}
|
|
|
|
|
2006-11-08 14:47:33 +08:00
|
|
|
static GenericValue executeLShrInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
2001-08-27 13:16:50 +08:00
|
|
|
GenericValue Dest;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
if (const IntegerType *ITy = cast<IntegerType>(Ty)) {
|
|
|
|
unsigned BitWidth = ITy->getBitWidth();
|
|
|
|
if (BitWidth <= 8)
|
|
|
|
Dest.Int8Val = ((uint8_t)Src1.Int8Val) >> ((uint32_t)Src2.Int8Val);
|
|
|
|
else if (BitWidth <= 16)
|
|
|
|
Dest.Int16Val = ((uint16_t)Src1.Int16Val) >> ((uint32_t)Src2.Int8Val);
|
|
|
|
else if (BitWidth <= 32)
|
|
|
|
Dest.Int32Val = ((uint32_t)Src1.Int32Val) >> ((uint32_t)Src2.Int8Val);
|
|
|
|
else if (BitWidth <= 64)
|
|
|
|
Dest.Int64Val = ((uint64_t)Src1.Int64Val) >> ((uint32_t)Src2.Int8Val);
|
|
|
|
else {
|
|
|
|
cerr << "Integer types > 64 bits not supported: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
2007-01-18 10:12:51 +08:00
|
|
|
maskToBitWidth(Dest, BitWidth);
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
} else {
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "Unhandled type for LShr instruction: " << *Ty << "\n";
|
2006-11-08 14:47:33 +08:00
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeAShrInst(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
if (const IntegerType *ITy = cast<IntegerType>(Ty)) {
|
|
|
|
unsigned BitWidth = ITy->getBitWidth();
|
|
|
|
if (BitWidth <= 8)
|
|
|
|
Dest.Int8Val = ((int8_t)Src1.Int8Val) >> ((int32_t)Src2.Int8Val);
|
|
|
|
else if (BitWidth <= 16)
|
|
|
|
Dest.Int16Val = ((int16_t)Src1.Int16Val) >> ((int32_t)Src2.Int8Val);
|
|
|
|
else if (BitWidth <= 32)
|
|
|
|
Dest.Int32Val = ((int32_t)Src1.Int32Val) >> ((int32_t)Src2.Int8Val);
|
|
|
|
else if (BitWidth <= 64)
|
|
|
|
Dest.Int64Val = ((int64_t)Src1.Int64Val) >> ((int32_t)Src2.Int8Val);
|
|
|
|
else {
|
|
|
|
cerr << "Integer types > 64 bits not supported: " << *Ty << "\n"; \
|
|
|
|
abort();
|
|
|
|
}
|
2007-01-18 10:12:51 +08:00
|
|
|
maskToBitWidth(Dest, BitWidth);
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
} else {
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "Unhandled type for AShr instruction: " << *Ty << "\n";
|
2003-04-23 05:22:33 +08:00
|
|
|
abort();
|
2001-08-27 13:16:50 +08:00
|
|
|
}
|
2003-12-11 08:22:59 +08:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitShl(ShiftInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
const Type *Ty = I.getOperand(0)->getType();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
|
|
|
GenericValue Dest;
|
|
|
|
Dest = executeShlInst (Src1, Src2, Ty);
|
|
|
|
SetValue(&I, Dest, SF);
|
|
|
|
}
|
|
|
|
|
2006-11-08 14:47:33 +08:00
|
|
|
void Interpreter::visitLShr(ShiftInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
const Type *Ty = I.getOperand(0)->getType();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
|
|
|
GenericValue Dest;
|
|
|
|
Dest = executeLShrInst (Src1, Src2, Ty);
|
|
|
|
SetValue(&I, Dest, SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitAShr(ShiftInst &I) {
|
2003-12-11 08:22:59 +08:00
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
const Type *Ty = I.getOperand(0)->getType();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
|
|
|
GenericValue Dest;
|
2006-11-08 14:47:33 +08:00
|
|
|
Dest = executeAShrInst (Src1, Src2, Ty);
|
2002-06-26 00:13:21 +08:00
|
|
|
SetValue(&I, Dest, SF);
|
2001-08-27 13:16:50 +08:00
|
|
|
}
|
|
|
|
|
2007-01-18 09:25:42 +08:00
|
|
|
#define INTEGER_ASSIGN(DEST, BITWIDTH, VAL) \
|
|
|
|
{ \
|
|
|
|
uint64_t Mask = (1ull << BITWIDTH) - 1; \
|
|
|
|
if (BITWIDTH == 1) { \
|
|
|
|
Dest.Int1Val = (bool) (VAL & Mask); \
|
|
|
|
} else if (BITWIDTH <= 8) { \
|
|
|
|
Dest.Int8Val = (uint8_t) (VAL & Mask); \
|
|
|
|
} else if (BITWIDTH <= 16) { \
|
|
|
|
Dest.Int16Val = (uint16_t) (VAL & Mask); \
|
|
|
|
} else if (BITWIDTH <= 32) { \
|
|
|
|
Dest.Int32Val = (uint32_t) (VAL & Mask); \
|
|
|
|
} else \
|
|
|
|
Dest.Int64Val = (uint64_t) (VAL & Mask); \
|
|
|
|
}
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
|
|
|
|
GenericValue Interpreter::executeTruncInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
const IntegerType *SITy = cast<IntegerType>(SrcTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
|
|
|
unsigned SBitWidth = SITy->getBitWidth();
|
|
|
|
assert(SBitWidth <= 64 && DBitWidth <= 64 &&
|
|
|
|
"Integer types > 64 bits not supported");
|
|
|
|
assert(SBitWidth > DBitWidth && "Invalid truncate");
|
|
|
|
|
|
|
|
// Mask the source value to its actual bit width. This ensures that any
|
|
|
|
// high order bits are cleared.
|
|
|
|
uint64_t Mask = (1ULL << DBitWidth) - 1;
|
|
|
|
uint64_t MaskedVal = 0;
|
|
|
|
if (SBitWidth <= 8)
|
|
|
|
MaskedVal = Src.Int8Val & Mask;
|
|
|
|
else if (SBitWidth <= 16)
|
|
|
|
MaskedVal = Src.Int16Val & Mask;
|
|
|
|
else if (SBitWidth <= 32)
|
|
|
|
MaskedVal = Src.Int32Val & Mask;
|
|
|
|
else
|
|
|
|
MaskedVal = Src.Int64Val & Mask;
|
|
|
|
|
|
|
|
INTEGER_ASSIGN(Dest, DBitWidth, MaskedVal);
|
|
|
|
return Dest;
|
|
|
|
}
|
2001-08-27 13:16:50 +08:00
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
GenericValue Interpreter::executeSExtInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
2002-08-28 06:33:45 +08:00
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
const IntegerType *SITy = cast<IntegerType>(SrcTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
|
|
|
unsigned SBitWidth = SITy->getBitWidth();
|
|
|
|
assert(SBitWidth <= 64 && DBitWidth <= 64 &&
|
|
|
|
"Integer types > 64 bits not supported");
|
|
|
|
assert(SBitWidth < DBitWidth && "Invalid sign extend");
|
2007-01-20 16:32:52 +08:00
|
|
|
|
|
|
|
// Normalize to a 64-bit value.
|
|
|
|
uint64_t Normalized = 0;
|
|
|
|
if (SBitWidth <= 8)
|
|
|
|
Normalized = Src.Int8Val;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
else if (SBitWidth <= 16)
|
2007-01-20 16:32:52 +08:00
|
|
|
Normalized = Src.Int16Val;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
else if (SBitWidth <= 32)
|
2007-01-20 16:32:52 +08:00
|
|
|
Normalized = Src.Int32Val;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
else
|
2007-01-20 16:32:52 +08:00
|
|
|
Normalized = Src.Int64Val;
|
|
|
|
|
2007-01-21 04:12:29 +08:00
|
|
|
Normalized = doSignExtension(Normalized, SITy);
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
|
|
|
|
// Now that we have a sign extended value, assign it to the destination
|
2007-01-20 16:32:52 +08:00
|
|
|
INTEGER_ASSIGN(Dest, DBitWidth, Normalized);
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
return Dest;
|
|
|
|
}
|
2001-08-27 13:16:50 +08:00
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
GenericValue Interpreter::executeZExtInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
const IntegerType *SITy = cast<IntegerType>(SrcTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
|
|
|
unsigned SBitWidth = SITy->getBitWidth();
|
|
|
|
assert(SBitWidth <= 64 && DBitWidth <= 64 &&
|
|
|
|
"Integer types > 64 bits not supported");
|
|
|
|
assert(SBitWidth < DBitWidth && "Invalid sign extend");
|
|
|
|
uint64_t Extended = 0;
|
|
|
|
if (SBitWidth == 1)
|
2006-11-27 09:05:10 +08:00
|
|
|
// For sign extension from bool, we must extend the source bits.
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
Extended = (uint64_t) (Src.Int1Val & 1);
|
|
|
|
else if (SBitWidth <= 8)
|
|
|
|
Extended = (uint64_t) (uint8_t)Src.Int8Val;
|
|
|
|
else if (SBitWidth <= 16)
|
|
|
|
Extended = (uint64_t) (uint16_t)Src.Int16Val;
|
|
|
|
else if (SBitWidth <= 32)
|
|
|
|
Extended = (uint64_t) (uint32_t)Src.Int32Val;
|
|
|
|
else
|
|
|
|
Extended = (uint64_t) Src.Int64Val;
|
|
|
|
|
|
|
|
// Now that we have a sign extended value, assign it to the destination
|
|
|
|
INTEGER_ASSIGN(Dest, DBitWidth, Extended);
|
|
|
|
return Dest;
|
|
|
|
}
|
2002-08-28 06:33:45 +08:00
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
GenericValue Interpreter::executeFPTruncInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(SrcTy == Type::DoubleTy && DstTy == Type::FloatTy &&
|
|
|
|
"Invalid FPTrunc instruction");
|
|
|
|
Dest.FloatVal = (float) Src.DoubleVal;
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeFPExtInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(SrcTy == Type::FloatTy && DstTy == Type::DoubleTy &&
|
|
|
|
"Invalid FPTrunc instruction");
|
|
|
|
Dest.DoubleVal = (double) Src.FloatVal;
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeFPToUIInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
|
|
|
assert(DBitWidth <= 64 && "Integer types > 64 bits not supported");
|
|
|
|
assert(SrcTy->isFloatingPoint() && "Invalid FPToUI instruction");
|
|
|
|
uint64_t Converted = 0;
|
|
|
|
if (SrcTy->getTypeID() == Type::FloatTyID)
|
|
|
|
Converted = (uint64_t) Src.FloatVal;
|
|
|
|
else
|
|
|
|
Converted = (uint64_t) Src.DoubleVal;
|
|
|
|
|
|
|
|
INTEGER_ASSIGN(Dest, DBitWidth, Converted);
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeFPToSIInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
|
|
|
assert(DBitWidth <= 64 && "Integer types > 64 bits not supported");
|
|
|
|
assert(SrcTy->isFloatingPoint() && "Invalid FPToSI instruction");
|
|
|
|
int64_t Converted = 0;
|
|
|
|
if (SrcTy->getTypeID() == Type::FloatTyID)
|
|
|
|
Converted = (int64_t) Src.FloatVal;
|
|
|
|
else
|
|
|
|
Converted = (int64_t) Src.DoubleVal;
|
|
|
|
|
|
|
|
INTEGER_ASSIGN(Dest, DBitWidth, Converted);
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeUIToFPInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *SITy = cast<IntegerType>(SrcTy);
|
|
|
|
unsigned SBitWidth = SITy->getBitWidth();
|
|
|
|
assert(SBitWidth <= 64 && "Integer types > 64 bits not supported");
|
|
|
|
assert(DstTy->isFloatingPoint() && "Invalid UIToFP instruction");
|
|
|
|
uint64_t Converted = 0;
|
|
|
|
if (SBitWidth == 1)
|
|
|
|
Converted = (uint64_t) Src.Int1Val;
|
|
|
|
else if (SBitWidth <= 8)
|
|
|
|
Converted = (uint64_t) Src.Int8Val;
|
|
|
|
else if (SBitWidth <= 16)
|
|
|
|
Converted = (uint64_t) Src.Int16Val;
|
|
|
|
else if (SBitWidth <= 32)
|
|
|
|
Converted = (uint64_t) Src.Int32Val;
|
|
|
|
else
|
|
|
|
Converted = (uint64_t) Src.Int64Val;
|
|
|
|
|
|
|
|
if (DstTy->getTypeID() == Type::FloatTyID)
|
|
|
|
Dest.FloatVal = (float) Converted;
|
|
|
|
else
|
|
|
|
Dest.DoubleVal = (double) Converted;
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeSIToFPInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *SITy = cast<IntegerType>(SrcTy);
|
|
|
|
unsigned SBitWidth = SITy->getBitWidth();
|
|
|
|
assert(SBitWidth <= 64 && "Integer types > 64 bits not supported");
|
|
|
|
assert(DstTy->isFloatingPoint() && "Invalid UIToFP instruction");
|
|
|
|
int64_t Converted = 0;
|
|
|
|
if (SBitWidth == 1)
|
|
|
|
Converted = 0LL - Src.Int1Val;
|
|
|
|
else if (SBitWidth <= 8)
|
|
|
|
Converted = (int64_t) (int8_t)Src.Int8Val;
|
|
|
|
else if (SBitWidth <= 16)
|
|
|
|
Converted = (int64_t) (int16_t)Src.Int16Val;
|
|
|
|
else if (SBitWidth <= 32)
|
|
|
|
Converted = (int64_t) (int32_t)Src.Int32Val;
|
|
|
|
else
|
|
|
|
Converted = (int64_t) Src.Int64Val;
|
|
|
|
|
|
|
|
if (DstTy->getTypeID() == Type::FloatTyID)
|
|
|
|
Dest.FloatVal = (float) Converted;
|
|
|
|
else
|
|
|
|
Dest.DoubleVal = (double) Converted;
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executePtrToIntInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
|
|
|
assert(DBitWidth <= 64 && "Integer types > 64 bits not supported");
|
|
|
|
assert(isa<PointerType>(SrcTy) && "Invalid PtrToInt instruction");
|
|
|
|
INTEGER_ASSIGN(Dest, DBitWidth, (intptr_t) Src.PointerVal);
|
2002-08-28 06:33:45 +08:00
|
|
|
return Dest;
|
2001-08-27 13:16:50 +08:00
|
|
|
}
|
2001-08-24 01:05:04 +08:00
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
GenericValue Interpreter::executeIntToPtrInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *SITy = cast<IntegerType>(SrcTy);
|
|
|
|
unsigned SBitWidth = SITy->getBitWidth();
|
|
|
|
assert(SBitWidth <= 64 && "Integer types > 64 bits not supported");
|
|
|
|
assert(isa<PointerType>(DstTy) && "Invalid PtrToInt instruction");
|
|
|
|
uint64_t Converted = 0;
|
|
|
|
if (SBitWidth == 1)
|
|
|
|
Converted = (uint64_t) Src.Int1Val;
|
|
|
|
else if (SBitWidth <= 8)
|
|
|
|
Converted = (uint64_t) Src.Int8Val;
|
|
|
|
else if (SBitWidth <= 16)
|
|
|
|
Converted = (uint64_t) Src.Int16Val;
|
|
|
|
else if (SBitWidth <= 32)
|
|
|
|
Converted = (uint64_t) Src.Int32Val;
|
|
|
|
else
|
|
|
|
Converted = (uint64_t) Src.Int64Val;
|
|
|
|
|
|
|
|
Dest.PointerVal = (PointerTy) Converted;
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeBitCastInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
if (isa<PointerType>(DstTy)) {
|
|
|
|
assert(isa<PointerType>(SrcTy) && "Invalid BitCast");
|
|
|
|
Dest.PointerVal = Src.PointerVal;
|
2007-01-15 10:27:26 +08:00
|
|
|
} else if (DstTy->isInteger()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
|
|
|
if (SrcTy == Type::FloatTy) {
|
|
|
|
Dest.Int32Val = FloatToBits(Src.FloatVal);
|
|
|
|
} else if (SrcTy == Type::DoubleTy) {
|
|
|
|
Dest.Int64Val = DoubleToBits(Src.DoubleVal);
|
2007-01-15 10:27:26 +08:00
|
|
|
} else if (SrcTy->isInteger()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
const IntegerType *SITy = cast<IntegerType>(SrcTy);
|
|
|
|
unsigned SBitWidth = SITy->getBitWidth();
|
|
|
|
assert(SBitWidth <= 64 && "Integer types > 64 bits not supported");
|
|
|
|
assert(SBitWidth == DBitWidth && "Invalid BitCast");
|
|
|
|
if (SBitWidth == 1)
|
|
|
|
Dest.Int1Val = Src.Int1Val;
|
|
|
|
else if (SBitWidth <= 8)
|
|
|
|
Dest.Int8Val = Src.Int8Val;
|
|
|
|
else if (SBitWidth <= 16)
|
|
|
|
Dest.Int16Val = Src.Int16Val;
|
|
|
|
else if (SBitWidth <= 32)
|
|
|
|
Dest.Int32Val = Src.Int32Val;
|
|
|
|
else
|
|
|
|
Dest.Int64Val = Src.Int64Val;
|
2007-01-18 10:12:51 +08:00
|
|
|
maskToBitWidth(Dest, DBitWidth);
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
} else
|
|
|
|
assert(0 && "Invalid BitCast");
|
|
|
|
} else if (DstTy == Type::FloatTy) {
|
2007-01-15 10:27:26 +08:00
|
|
|
if (SrcTy->isInteger())
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
Dest.FloatVal = BitsToFloat(Src.Int32Val);
|
|
|
|
else
|
|
|
|
Dest.FloatVal = Src.FloatVal;
|
|
|
|
} else if (DstTy == Type::DoubleTy) {
|
2007-01-15 10:27:26 +08:00
|
|
|
if (SrcTy->isInteger())
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
Dest.DoubleVal = BitsToDouble(Src.Int64Val);
|
|
|
|
else
|
|
|
|
Dest.DoubleVal = Src.DoubleVal;
|
|
|
|
} else
|
|
|
|
assert(0 && "Invalid Bitcast");
|
|
|
|
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitTruncInst(TruncInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executeTruncInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitSExtInst(SExtInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executeSExtInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitZExtInst(ZExtInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executeZExtInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitFPTruncInst(FPTruncInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executeFPTruncInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitFPExtInst(FPExtInst &I) {
|
2003-05-11 05:22:39 +08:00
|
|
|
ExecutionContext &SF = ECStack.back();
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
SetValue(&I, executeFPExtInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitUIToFPInst(UIToFPInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executeUIToFPInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitSIToFPInst(SIToFPInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executeSIToFPInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitFPToUIInst(FPToUIInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executeFPToUIInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitFPToSIInst(FPToSIInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executeFPToSIInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitPtrToIntInst(PtrToIntInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executePtrToIntInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitIntToPtrInst(IntToPtrInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executeIntToPtrInst(I.getOperand(0), I.getType(), SF), SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::visitBitCastInst(BitCastInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
SetValue(&I, executeBitCastInst(I.getOperand(0), I.getType(), SF), SF);
|
2002-08-28 06:33:45 +08:00
|
|
|
}
|
2001-08-24 01:05:04 +08:00
|
|
|
|
2003-11-08 05:20:47 +08:00
|
|
|
#define IMPLEMENT_VAARG(TY) \
|
|
|
|
case Type::TY##TyID: Dest.TY##Val = Src.TY##Val; break
|
|
|
|
|
|
|
|
void Interpreter::visitVAArgInst(VAArgInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
|
2004-02-26 07:01:48 +08:00
|
|
|
// Get the incoming valist parameter. LLI treats the valist as a
|
|
|
|
// (ec-stack-depth var-arg-index) pair.
|
2003-11-08 05:20:47 +08:00
|
|
|
GenericValue VAList = getOperandValue(I.getOperand(0), SF);
|
2004-02-26 07:01:48 +08:00
|
|
|
GenericValue Dest;
|
|
|
|
GenericValue Src = ECStack[VAList.UIntPairVal.first]
|
2005-04-22 06:43:08 +08:00
|
|
|
.VarArgs[VAList.UIntPairVal.second];
|
2003-11-08 05:20:47 +08:00
|
|
|
const Type *Ty = I.getType();
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case Type::IntegerTyID: {
|
|
|
|
unsigned BitWidth = cast<IntegerType>(Ty)->getBitWidth();
|
|
|
|
if (BitWidth == 1)
|
|
|
|
Dest.Int1Val = Src.Int1Val;
|
|
|
|
else if (BitWidth <= 8)
|
|
|
|
Dest.Int8Val = Src.Int8Val;
|
|
|
|
else if (BitWidth <= 16)
|
|
|
|
Dest.Int16Val = Src.Int16Val;
|
|
|
|
else if (BitWidth <= 32)
|
|
|
|
Dest.Int32Val = Src.Int32Val;
|
|
|
|
else if (BitWidth <= 64)
|
|
|
|
Dest.Int64Val = Src.Int64Val;
|
|
|
|
else
|
|
|
|
assert("Integer types > 64 bits not supported");
|
2007-01-18 10:12:51 +08:00
|
|
|
maskToBitWidth(Dest, BitWidth);
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
}
|
2003-11-08 05:20:47 +08:00
|
|
|
IMPLEMENT_VAARG(Pointer);
|
|
|
|
IMPLEMENT_VAARG(Float);
|
|
|
|
IMPLEMENT_VAARG(Double);
|
|
|
|
default:
|
2006-12-07 09:30:32 +08:00
|
|
|
cerr << "Unhandled dest type for vaarg instruction: " << *Ty << "\n";
|
2003-11-08 05:20:47 +08:00
|
|
|
abort();
|
|
|
|
}
|
2005-04-22 06:43:08 +08:00
|
|
|
|
2003-11-08 05:20:47 +08:00
|
|
|
// Set the Value of this Instruction.
|
|
|
|
SetValue(&I, Dest, SF);
|
2005-06-19 02:34:52 +08:00
|
|
|
|
|
|
|
// Move the pointer to the next vararg.
|
|
|
|
++VAList.UIntPairVal.second;
|
2003-11-08 05:20:47 +08:00
|
|
|
}
|
|
|
|
|
2001-08-24 01:05:04 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Dispatch and Execution Code
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
2003-05-09 00:18:31 +08:00
|
|
|
// callFunction - Execute the specified function...
|
2001-08-24 01:05:04 +08:00
|
|
|
//
|
2003-05-09 00:18:31 +08:00
|
|
|
void Interpreter::callFunction(Function *F,
|
|
|
|
const std::vector<GenericValue> &ArgVals) {
|
2005-04-22 06:43:08 +08:00
|
|
|
assert((ECStack.empty() || ECStack.back().Caller.getInstruction() == 0 ||
|
|
|
|
ECStack.back().Caller.arg_size() == ArgVals.size()) &&
|
|
|
|
"Incorrect number of arguments passed into function call!");
|
2003-09-18 01:26:22 +08:00
|
|
|
// Make a new stack frame... and fill it in.
|
|
|
|
ECStack.push_back(ExecutionContext());
|
|
|
|
ExecutionContext &StackFrame = ECStack.back();
|
2003-05-09 00:18:31 +08:00
|
|
|
StackFrame.CurFunction = F;
|
2003-11-07 13:22:49 +08:00
|
|
|
|
|
|
|
// Special handling for external functions.
|
|
|
|
if (F->isExternal()) {
|
|
|
|
GenericValue Result = callExternalFunction (F, ArgVals);
|
|
|
|
// Simulate a 'ret' instruction of the appropriate type.
|
|
|
|
popStackAndReturnValueToCaller (F->getReturnType (), Result);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Get pointers to first LLVM BB & Instruction in function.
|
2003-05-09 00:06:52 +08:00
|
|
|
StackFrame.CurBB = F->begin();
|
2001-08-24 01:05:04 +08:00
|
|
|
StackFrame.CurInst = StackFrame.CurBB->begin();
|
2001-09-10 12:49:44 +08:00
|
|
|
|
2002-04-08 04:49:59 +08:00
|
|
|
// Run through the function arguments and initialize their values...
|
2005-03-15 12:54:21 +08:00
|
|
|
assert((ArgVals.size() == F->arg_size() ||
|
2005-04-22 06:43:08 +08:00
|
|
|
(ArgVals.size() > F->arg_size() && F->getFunctionType()->isVarArg()))&&
|
2002-04-08 04:49:59 +08:00
|
|
|
"Invalid number of values passed to function invocation!");
|
2003-05-09 00:06:52 +08:00
|
|
|
|
|
|
|
// Handle non-varargs arguments...
|
2001-09-10 12:49:44 +08:00
|
|
|
unsigned i = 0;
|
2005-03-15 12:54:21 +08:00
|
|
|
for (Function::arg_iterator AI = F->arg_begin(), E = F->arg_end(); AI != E; ++AI, ++i)
|
2002-06-26 00:13:21 +08:00
|
|
|
SetValue(AI, ArgVals[i], StackFrame);
|
2003-05-09 00:06:52 +08:00
|
|
|
|
|
|
|
// Handle varargs arguments...
|
|
|
|
StackFrame.VarArgs.assign(ArgVals.begin()+i, ArgVals.end());
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::run() {
|
2003-09-05 07:15:40 +08:00
|
|
|
while (!ECStack.empty()) {
|
2003-10-25 03:59:01 +08:00
|
|
|
// Interpret a single instruction & increment the "PC".
|
|
|
|
ExecutionContext &SF = ECStack.back(); // Current stack frame
|
|
|
|
Instruction &I = *SF.CurInst++; // Increment before execute
|
2005-04-22 06:43:08 +08:00
|
|
|
|
2003-10-25 03:59:01 +08:00
|
|
|
// Track the number of dynamic instructions executed.
|
|
|
|
++NumDynamicInsts;
|
2001-08-24 01:05:04 +08:00
|
|
|
|
2006-11-28 07:54:50 +08:00
|
|
|
DOUT << "About to interpret: " << I;
|
2003-10-25 03:59:01 +08:00
|
|
|
visit(I); // Dispatch to one of the visit* methods...
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
}
|