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
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file 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"
|
2007-03-03 14:22:22 +08:00
|
|
|
#include "llvm/ADT/APInt.h"
|
2004-09-02 06:55:40 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2008-07-09 01:25:49 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2004-09-02 06:55:40 +08:00
|
|
|
#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"
|
2007-10-12 03:40:35 +08:00
|
|
|
#include <algorithm>
|
2008-02-20 19:08:44 +08:00
|
|
|
#include <cmath>
|
|
|
|
#include <cstring>
|
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
|
|
|
|
2008-07-09 01:25:49 +08:00
|
|
|
static cl::opt<bool> PrintVolatile("interpreter-print-volatile", cl::Hidden,
|
|
|
|
cl::desc("make the interpreter print every volatile load and store"));
|
|
|
|
|
2001-10-15 21:25:40 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2007-03-03 14:22:22 +08:00
|
|
|
// Various Helper Functions
|
2001-10-15 21:25:40 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2003-12-28 17:44:37 +08:00
|
|
|
|
2007-03-03 14:22:22 +08:00
|
|
|
static inline uint64_t doSignExtension(uint64_t Val, const IntegerType* ITy) {
|
2007-01-21 04:12:29 +08:00
|
|
|
// 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;
|
|
|
|
}
|
|
|
|
|
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) \
|
2007-03-06 11:09:31 +08:00
|
|
|
case Type::TY##TyID: \
|
|
|
|
Dest.TY##Val = Src1.TY##Val OP Src2.TY##Val; \
|
|
|
|
break
|
2001-08-24 01:05:04 +08:00
|
|
|
|
2007-03-06 11:09:31 +08:00
|
|
|
#define IMPLEMENT_INTEGER_BINOP1(OP, 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 Type::IntegerTyID: { \
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = Src1.IntVal OP Src2.IntVal; \
|
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; \
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-03-03 14:22:22 +08:00
|
|
|
static void executeAddInst(GenericValue &Dest, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_BINOP1(+, 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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-03 14:22:22 +08:00
|
|
|
static void executeSubInst(GenericValue &Dest, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_BINOP1(-, 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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-03 14:22:22 +08:00
|
|
|
static void executeMulInst(GenericValue &Dest, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
2004-06-18 02:19:28 +08:00
|
|
|
switch (Ty->getTypeID()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_BINOP1(*, 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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-03 14:22:22 +08:00
|
|
|
static void executeFDivInst(GenericValue &Dest, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
2006-10-26 14:15:43 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-03 14:22:22 +08:00
|
|
|
static void executeFRemInst(GenericValue &Dest, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-06 11:09:31 +08:00
|
|
|
#define IMPLEMENT_INTEGER_ICMP(OP, TY) \
|
|
|
|
case Type::IntegerTyID: \
|
|
|
|
Dest.IntVal = APInt(1,Src1.IntVal.OP(Src2.IntVal)); \
|
|
|
|
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-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = APInt(1,(void*)(intptr_t)Src1.PointerVal OP \
|
|
|
|
(void*)(intptr_t)Src2.PointerVal); \
|
|
|
|
break;
|
2003-04-24 03:55:35 +08:00
|
|
|
|
2006-12-23 14:05:41 +08:00
|
|
|
static GenericValue executeICMP_EQ(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_ICMP(eq,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
|
|
|
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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_ICMP(ne,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
|
|
|
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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_ICMP(ult,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
|
|
|
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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_ICMP(slt,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
|
|
|
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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_ICMP(ugt,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
|
|
|
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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_ICMP(sgt,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
|
|
|
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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_ICMP(ule,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
|
|
|
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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_ICMP(sle,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
|
|
|
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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_ICMP(uge,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
|
|
|
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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
IMPLEMENT_INTEGER_ICMP(sge,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
|
|
|
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-03-06 11:09:31 +08:00
|
|
|
case Type::TY##TyID: \
|
|
|
|
Dest.IntVal = APInt(1,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;
|
|
|
|
}
|
|
|
|
|
2008-02-20 19:10:28 +08:00
|
|
|
#define IMPLEMENT_UNORDERED(TY, X,Y) \
|
|
|
|
if (TY == Type::FloatTy) { \
|
|
|
|
if (X.FloatVal != X.FloatVal || Y.FloatVal != Y.FloatVal) { \
|
|
|
|
Dest.IntVal = APInt(1,true); \
|
|
|
|
return Dest; \
|
|
|
|
} \
|
|
|
|
} else if (X.DoubleVal != X.DoubleVal || Y.DoubleVal != Y.DoubleVal) { \
|
|
|
|
Dest.IntVal = APInt(1,true); \
|
|
|
|
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_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)
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = APInt(1,(Src1.FloatVal == Src1.FloatVal &&
|
|
|
|
Src2.FloatVal == Src2.FloatVal));
|
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-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = APInt(1,(Src1.DoubleVal == Src1.DoubleVal &&
|
|
|
|
Src2.DoubleVal == Src2.DoubleVal));
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UNO(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
if (Ty == Type::FloatTy)
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = APInt(1,(Src1.FloatVal != Src1.FloatVal ||
|
|
|
|
Src2.FloatVal != Src2.FloatVal));
|
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-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = APInt(1,(Src1.DoubleVal != Src1.DoubleVal ||
|
|
|
|
Src2.DoubleVal != Src2.DoubleVal));
|
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;
|
|
|
|
}
|
|
|
|
|
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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
case FCmpInst::FCMP_FALSE: R.IntVal = APInt(1,false); break;
|
|
|
|
case FCmpInst::FCMP_TRUE: R.IntVal = APInt(1,true); 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
|
|
|
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-03-06 11:09:31 +08:00
|
|
|
Result.IntVal = APInt(1, false);
|
2006-12-23 14:05:41 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
case FCmpInst::FCMP_TRUE: {
|
|
|
|
GenericValue Result;
|
2007-03-06 11:09:31 +08:00
|
|
|
Result.IntVal = APInt(1, 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()) {
|
2007-03-03 14:22:22 +08:00
|
|
|
case Instruction::Add: executeAddInst (R, Src1, Src2, Ty); break;
|
|
|
|
case Instruction::Sub: executeSubInst (R, Src1, Src2, Ty); break;
|
|
|
|
case Instruction::Mul: executeMulInst (R, Src1, Src2, Ty); break;
|
|
|
|
case Instruction::FDiv: executeFDivInst (R, Src1, Src2, Ty); break;
|
|
|
|
case Instruction::FRem: executeFRemInst (R, Src1, Src2, Ty); break;
|
2007-03-06 11:09:31 +08:00
|
|
|
case Instruction::UDiv: R.IntVal = Src1.IntVal.udiv(Src2.IntVal); break;
|
|
|
|
case Instruction::SDiv: R.IntVal = Src1.IntVal.sdiv(Src2.IntVal); break;
|
|
|
|
case Instruction::URem: R.IntVal = Src1.IntVal.urem(Src2.IntVal); break;
|
|
|
|
case Instruction::SRem: R.IntVal = Src1.IntVal.srem(Src2.IntVal); break;
|
|
|
|
case Instruction::And: R.IntVal = Src1.IntVal & Src2.IntVal; break;
|
|
|
|
case Instruction::Or: R.IntVal = Src1.IntVal | Src2.IntVal; break;
|
|
|
|
case Instruction::Xor: R.IntVal = Src1.IntVal ^ Src2.IntVal; 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-03-06 11:09:31 +08:00
|
|
|
return Src1.IntVal == 0 ? Src3 : Src2;
|
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);
|
2007-03-06 11:09:31 +08:00
|
|
|
GenericValue R = executeSelectInst(Src1, Src2, Src3);
|
2004-04-21 00:43:21 +08:00
|
|
|
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 ();
|
2007-03-06 11:09:31 +08:00
|
|
|
exit (GV.IntVal.zextOrTrunc(32).getZExtValue());
|
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 {
|
2007-06-02 06:23:29 +08:00
|
|
|
memset(&ExitValue.Untyped, 0, sizeof(ExitValue.Untyped));
|
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-03-06 11:09:31 +08:00
|
|
|
if (getOperandValue(Cond, SF).IntVal == 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)
|
2007-03-06 11:09:31 +08:00
|
|
|
if (executeICMP_EQ(CondVal, getOperandValue(I.getOperand(i), SF), ElTy)
|
|
|
|
.IntVal != 0) {
|
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...
|
2007-03-06 11:09:31 +08:00
|
|
|
unsigned NumElements =
|
|
|
|
getOperandValue(I.getOperand(0), SF).IntVal.getZExtValue();
|
|
|
|
|
Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
llvm-svn: 43620
2007-11-02 04:53:16 +08:00
|
|
|
unsigned TypeSize = (size_t)TD.getABITypeSize(Ty);
|
2007-03-06 11:09:31 +08:00
|
|
|
|
2007-10-12 03:40:35 +08:00
|
|
|
// Avoid malloc-ing zero bytes, use max()...
|
|
|
|
unsigned MemToAlloc = std::max(1U, NumElements * TypeSize);
|
2001-08-27 13:16:50 +08:00
|
|
|
|
|
|
|
// Allocate enough memory to hold the type...
|
2007-03-06 11:09:31 +08:00
|
|
|
void *Memory = malloc(MemToAlloc);
|
|
|
|
|
|
|
|
DOUT << "Allocated Type: " << *Ty << " (" << TypeSize << " bytes) x "
|
|
|
|
<< NumElements << " (Total: " << MemToAlloc << ") at "
|
2007-03-09 07:37:24 +08:00
|
|
|
<< uintptr_t(Memory) << '\n';
|
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!");
|
|
|
|
|
2007-03-06 11:09:31 +08:00
|
|
|
uint64_t 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
|
|
|
|
2007-03-06 11:09:31 +08:00
|
|
|
Total += SLO->getElementOffset(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)
|
2007-03-06 11:09:31 +08:00
|
|
|
Idx = (int64_t)(int32_t)IdxGV.IntVal.getZExtValue();
|
2008-04-07 05:50:58 +08:00
|
|
|
else {
|
|
|
|
assert(BitWidth == 64 && "Invalid index type for getelementptr");
|
2007-03-06 11:09:31 +08:00
|
|
|
Idx = (int64_t)IdxGV.IntVal.getZExtValue();
|
2008-04-07 05:50:58 +08:00
|
|
|
}
|
Executive summary: getTypeSize -> getTypeStoreSize / getABITypeSize.
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
llvm-svn: 43620
2007-11-02 04:53:16 +08:00
|
|
|
Total += TD.getABITypeSize(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;
|
2007-03-06 11:09:31 +08:00
|
|
|
Result.PointerVal = ((char*)getOperandValue(Ptr, SF).PointerVal) + Total;
|
|
|
|
DOUT << "GEP Index " << Total << " bytes.\n";
|
2002-08-28 06:33:45 +08:00
|
|
|
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);
|
2007-03-03 16:38:04 +08:00
|
|
|
GenericValue Result;
|
|
|
|
LoadValueFromMemory(Result, Ptr, I.getType());
|
2002-06-26 00:13:21 +08:00
|
|
|
SetValue(&I, Result, SF);
|
2008-07-09 01:25:49 +08:00
|
|
|
if (I.isVolatile() && PrintVolatile)
|
|
|
|
cerr << "Volatile load " << I;
|
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());
|
2008-07-09 01:25:49 +08:00
|
|
|
if (I.isVolatile() && PrintVolatile)
|
|
|
|
cerr << "Volatile store: " << I;
|
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...
|
2007-04-17 05:50:40 +08:00
|
|
|
Function *F = CS.getCalledFunction();
|
|
|
|
if (F && F->isDeclaration ())
|
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.
|
|
|
|
//
|
2007-04-18 01:38:28 +08:00
|
|
|
BasicBlock::iterator me(CS.getInstruction());
|
2003-12-28 17:44:37 +08:00
|
|
|
BasicBlock *Parent = CS.getInstruction()->getParent();
|
2007-04-18 01:38:28 +08:00
|
|
|
bool atBegin(Parent->begin() == me);
|
|
|
|
if (!atBegin)
|
|
|
|
--me;
|
2003-12-28 17:44:37 +08:00
|
|
|
IL->LowerIntrinsicCall(cast<CallInst>(CS.getInstruction()));
|
|
|
|
|
|
|
|
// Restore the CurInst pointer to the first instruction newly inserted, if
|
|
|
|
// any.
|
2007-04-18 01:38:28 +08:00
|
|
|
if (atBegin) {
|
2003-12-28 17:44:37 +08:00
|
|
|
SF.CurInst = Parent->begin();
|
|
|
|
} else {
|
2007-04-18 01:38:28 +08:00
|
|
|
SF.CurInst = me;
|
2003-12-28 17:44:37 +08:00
|
|
|
++SF.CurInst;
|
|
|
|
}
|
2004-04-24 02:05:28 +08:00
|
|
|
return;
|
2003-12-28 17:44:37 +08:00
|
|
|
}
|
|
|
|
|
2007-04-17 05:50:40 +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);
|
2007-04-17 05:50:40 +08:00
|
|
|
uint16_t pNum = 1;
|
2003-11-08 03:59:08 +08:00
|
|
|
for (CallSite::arg_iterator i = SF.Caller.arg_begin(),
|
2007-04-17 05:50:40 +08:00
|
|
|
e = SF.Caller.arg_end(); i != e; ++i, ++pNum) {
|
2003-11-08 03:59:08 +08:00
|
|
|
Value *V = *i;
|
|
|
|
ArgVals.push_back(getOperandValue(V, SF));
|
2007-11-29 01:07:01 +08:00
|
|
|
// Promote all integral types whose size is < sizeof(i32) into i32.
|
|
|
|
// We do this by zero or sign extending the value as appropriate
|
|
|
|
// according to the parameter attributes
|
|
|
|
const Type *Ty = V->getType();
|
2008-02-20 19:10:28 +08:00
|
|
|
if (Ty->isInteger() && (ArgVals.back().IntVal.getBitWidth() < 32)) {
|
2008-09-26 05:00:45 +08:00
|
|
|
if (CS.paramHasAttr(pNum, Attribute::ZExt))
|
2007-11-29 01:07:01 +08:00
|
|
|
ArgVals.back().IntVal = ArgVals.back().IntVal.zext(32);
|
2008-09-26 05:00:45 +08:00
|
|
|
else if (CS.paramHasAttr(pNum, Attribute::SExt))
|
2007-11-29 01:07:01 +08:00
|
|
|
ArgVals.back().IntVal = ArgVals.back().IntVal.sext(32);
|
2008-02-20 19:10:28 +08:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2007-02-02 10:16:23 +08:00
|
|
|
void Interpreter::visitShl(BinaryOperator &I) {
|
2003-12-11 08:22:59 +08:00
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
|
|
|
GenericValue Dest;
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = Src1.IntVal.shl(Src2.IntVal.getZExtValue());
|
2003-12-11 08:22:59 +08:00
|
|
|
SetValue(&I, Dest, SF);
|
|
|
|
}
|
|
|
|
|
2007-02-02 10:16:23 +08:00
|
|
|
void Interpreter::visitLShr(BinaryOperator &I) {
|
2006-11-08 14:47:33 +08:00
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
|
|
|
GenericValue Dest;
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = Src1.IntVal.lshr(Src2.IntVal.getZExtValue());
|
2006-11-08 14:47:33 +08:00
|
|
|
SetValue(&I, Dest, SF);
|
|
|
|
}
|
|
|
|
|
2007-02-02 10:16:23 +08:00
|
|
|
void Interpreter::visitAShr(BinaryOperator &I) {
|
2003-12-11 08:22:59 +08:00
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
2007-03-06 11:09:31 +08:00
|
|
|
GenericValue Dest;
|
|
|
|
Dest.IntVal = Src1.IntVal.ashr(Src2.IntVal.getZExtValue());
|
2002-06-26 00:13:21 +08:00
|
|
|
SetValue(&I, Dest, SF);
|
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::executeTruncInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = Src.IntVal.trunc(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
|
|
|
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
|
|
|
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);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = Src.IntVal.sext(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
|
|
|
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) {
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = Src.IntVal.zext(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
|
|
|
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) {
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
2008-04-07 05:50:58 +08:00
|
|
|
assert(SrcVal->getType() == Type::DoubleTy && DstTy == Type::FloatTy &&
|
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
|
|
|
"Invalid FPTrunc instruction");
|
|
|
|
Dest.FloatVal = (float) Src.DoubleVal;
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeFPExtInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
2008-04-07 05:50:58 +08:00
|
|
|
assert(SrcVal->getType() == Type::FloatTy && DstTy == Type::DoubleTy &&
|
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
|
|
|
"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();
|
2007-03-06 11:09:31 +08:00
|
|
|
uint32_t DBitWidth = cast<IntegerType>(DstTy)->getBitWidth();
|
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 Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(SrcTy->isFloatingPoint() && "Invalid FPToUI instruction");
|
2007-03-03 16:38: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
|
|
|
if (SrcTy->getTypeID() == Type::FloatTyID)
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = APIntOps::RoundFloatToAPInt(Src.FloatVal, 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
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = APIntOps::RoundDoubleToAPInt(Src.DoubleVal, 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
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeFPToSIInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
2007-03-06 11:09:31 +08:00
|
|
|
uint32_t DBitWidth = cast<IntegerType>(DstTy)->getBitWidth();
|
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 Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(SrcTy->isFloatingPoint() && "Invalid FPToSI instruction");
|
2007-03-03 16:38: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
|
|
|
if (SrcTy->getTypeID() == Type::FloatTyID)
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = APIntOps::RoundFloatToAPInt(Src.FloatVal, 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
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = APIntOps::RoundDoubleToAPInt(Src.DoubleVal, 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
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeUIToFPInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(DstTy->isFloatingPoint() && "Invalid UIToFP instruction");
|
2007-03-03 16:38: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
|
|
|
if (DstTy->getTypeID() == Type::FloatTyID)
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.FloatVal = APIntOps::RoundAPIntToFloat(Src.IntVal);
|
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-03-06 11:09:31 +08:00
|
|
|
Dest.DoubleVal = APIntOps::RoundAPIntToDouble(Src.IntVal);
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeSIToFPInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
2007-01-21 08:29:26 +08:00
|
|
|
assert(DstTy->isFloatingPoint() && "Invalid SIToFP instruction");
|
2007-03-03 16:38: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
|
|
|
if (DstTy->getTypeID() == Type::FloatTyID)
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.FloatVal = APIntOps::RoundSignedAPIntToFloat(Src.IntVal);
|
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-03-06 11:09:31 +08:00
|
|
|
Dest.DoubleVal = APIntOps::RoundSignedAPIntToDouble(Src.IntVal);
|
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;
|
2007-03-06 11:09:31 +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::executePtrToIntInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
2007-03-06 11:09:31 +08:00
|
|
|
uint32_t DBitWidth = cast<IntegerType>(DstTy)->getBitWidth();
|
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 Dest, Src = getOperandValue(SrcVal, SF);
|
2008-04-07 05:50:58 +08:00
|
|
|
assert(isa<PointerType>(SrcVal->getType()) && "Invalid PtrToInt instruction");
|
2007-03-03 16:38:04 +08:00
|
|
|
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = APInt(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) {
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(isa<PointerType>(DstTy) && "Invalid PtrToInt instruction");
|
2007-03-03 16:38:04 +08:00
|
|
|
|
2007-03-06 11:46:41 +08:00
|
|
|
uint32_t PtrSize = TD.getPointerSizeInBits();
|
2007-03-06 11:41:50 +08:00
|
|
|
if (PtrSize != Src.IntVal.getBitWidth())
|
2007-03-06 11:46:41 +08:00
|
|
|
Src.IntVal = Src.IntVal.zextOrTrunc(PtrSize);
|
2007-03-06 11:41:50 +08:00
|
|
|
|
2007-04-27 02:19:35 +08:00
|
|
|
Dest.PointerVal = PointerTy(intptr_t(Src.IntVal.getZExtValue()));
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
if (SrcTy == Type::FloatTy) {
|
2007-05-04 11:37:38 +08:00
|
|
|
Dest.IntVal.zext(sizeof(Src.FloatVal) * 8);
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal.floatToBits(Src.FloatVal);
|
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 (SrcTy == Type::DoubleTy) {
|
2007-05-04 11:37:38 +08:00
|
|
|
Dest.IntVal.zext(sizeof(Src.DoubleVal) * 8);
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal.doubleToBits(Src.DoubleVal);
|
2007-01-15 10:27:26 +08:00
|
|
|
} else if (SrcTy->isInteger()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.IntVal = Src.IntVal;
|
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())
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.FloatVal = Src.IntVal.bitsToFloat();
|
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
|
|
|
|
Dest.FloatVal = Src.FloatVal;
|
|
|
|
} else if (DstTy == Type::DoubleTy) {
|
2007-01-15 10:27:26 +08:00
|
|
|
if (SrcTy->isInteger())
|
2007-03-06 11:09:31 +08:00
|
|
|
Dest.DoubleVal = Src.IntVal.bitsToDouble();
|
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
|
|
|
|
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]
|
2007-03-06 11:09:31 +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()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
case Type::IntegerTyID: Dest.IntVal = Src.IntVal;
|
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
|
|
|
}
|
|
|
|
|
2007-03-03 14:22:22 +08:00
|
|
|
GenericValue Interpreter::getConstantExprValue (ConstantExpr *CE,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
switch (CE->getOpcode()) {
|
|
|
|
case Instruction::Trunc:
|
|
|
|
return executeTruncInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::ZExt:
|
|
|
|
return executeZExtInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::SExt:
|
|
|
|
return executeSExtInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::FPTrunc:
|
|
|
|
return executeFPTruncInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::FPExt:
|
|
|
|
return executeFPExtInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::UIToFP:
|
|
|
|
return executeUIToFPInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::SIToFP:
|
|
|
|
return executeSIToFPInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::FPToUI:
|
|
|
|
return executeFPToUIInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::FPToSI:
|
|
|
|
return executeFPToSIInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::PtrToInt:
|
|
|
|
return executePtrToIntInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::IntToPtr:
|
|
|
|
return executeIntToPtrInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::BitCast:
|
|
|
|
return executeBitCastInst(CE->getOperand(0), CE->getType(), SF);
|
|
|
|
case Instruction::GetElementPtr:
|
|
|
|
return executeGEPOperation(CE->getOperand(0), gep_type_begin(CE),
|
|
|
|
gep_type_end(CE), SF);
|
2007-03-03 16:38:04 +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());
|
|
|
|
case Instruction::Select:
|
|
|
|
return executeSelectInst(getOperandValue(CE->getOperand(0), SF),
|
|
|
|
getOperandValue(CE->getOperand(1), SF),
|
|
|
|
getOperandValue(CE->getOperand(2), SF));
|
2007-03-03 14:22:22 +08:00
|
|
|
default :
|
|
|
|
break;
|
|
|
|
}
|
2007-03-03 16:38:04 +08:00
|
|
|
|
|
|
|
// The cases below here require a GenericValue parameter for the result
|
|
|
|
// so we initialize one, compute it and then return it.
|
2007-03-06 11:09:31 +08:00
|
|
|
GenericValue Op0 = getOperandValue(CE->getOperand(0), SF);
|
|
|
|
GenericValue Op1 = getOperandValue(CE->getOperand(1), SF);
|
2007-03-03 14:22:22 +08:00
|
|
|
GenericValue Dest;
|
2007-03-06 11:09:31 +08:00
|
|
|
const Type * Ty = CE->getOperand(0)->getType();
|
2007-03-03 14:22:22 +08:00
|
|
|
switch (CE->getOpcode()) {
|
2007-03-06 11:09:31 +08:00
|
|
|
case Instruction::Add: executeAddInst (Dest, Op0, Op1, Ty); break;
|
|
|
|
case Instruction::Sub: executeSubInst (Dest, Op0, Op1, Ty); break;
|
|
|
|
case Instruction::Mul: executeMulInst (Dest, Op0, Op1, Ty); break;
|
|
|
|
case Instruction::FDiv: executeFDivInst(Dest, Op0, Op1, Ty); break;
|
|
|
|
case Instruction::FRem: executeFRemInst(Dest, Op0, Op1, Ty); break;
|
|
|
|
case Instruction::SDiv: Dest.IntVal = Op0.IntVal.sdiv(Op1.IntVal); break;
|
|
|
|
case Instruction::UDiv: Dest.IntVal = Op0.IntVal.udiv(Op1.IntVal); break;
|
|
|
|
case Instruction::URem: Dest.IntVal = Op0.IntVal.urem(Op1.IntVal); break;
|
|
|
|
case Instruction::SRem: Dest.IntVal = Op0.IntVal.srem(Op1.IntVal); break;
|
|
|
|
case Instruction::And: Dest.IntVal = Op0.IntVal.And(Op1.IntVal); break;
|
|
|
|
case Instruction::Or: Dest.IntVal = Op0.IntVal.Or(Op1.IntVal); break;
|
|
|
|
case Instruction::Xor: Dest.IntVal = Op0.IntVal.Xor(Op1.IntVal); break;
|
|
|
|
case Instruction::Shl:
|
|
|
|
Dest.IntVal = Op0.IntVal.shl(Op1.IntVal.getZExtValue());
|
|
|
|
break;
|
|
|
|
case Instruction::LShr:
|
|
|
|
Dest.IntVal = Op0.IntVal.lshr(Op1.IntVal.getZExtValue());
|
|
|
|
break;
|
|
|
|
case Instruction::AShr:
|
|
|
|
Dest.IntVal = Op0.IntVal.ashr(Op1.IntVal.getZExtValue());
|
|
|
|
break;
|
2007-03-03 14:22:22 +08:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled ConstantExpr: " << *CE << "\n";
|
|
|
|
abort();
|
|
|
|
return GenericValue();
|
|
|
|
}
|
2007-03-03 16:38:04 +08:00
|
|
|
return Dest;
|
2007-03-03 14:22:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::getOperandValue(Value *V, ExecutionContext &SF) {
|
|
|
|
if (ConstantExpr *CE = dyn_cast<ConstantExpr>(V)) {
|
|
|
|
return getConstantExprValue(CE, SF);
|
|
|
|
} else if (Constant *CPV = dyn_cast<Constant>(V)) {
|
|
|
|
return getConstantValue(CPV);
|
|
|
|
} else if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) {
|
|
|
|
return PTOGV(getPointerToGlobal(GV));
|
|
|
|
} else {
|
|
|
|
return SF.Values[V];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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.
|
2007-01-31 04:08:39 +08:00
|
|
|
if (F->isDeclaration()) {
|
2003-11-07 13:22:49 +08:00
|
|
|
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;
|
2007-04-17 05:50:40 +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
|
|
|
}
|
|
|
|
|
2007-05-16 10:05:13 +08:00
|
|
|
|
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...
|
2007-09-22 02:30:39 +08:00
|
|
|
#if 0
|
|
|
|
// This is not safe, as visiting the instruction could lower it and free I.
|
2007-05-16 10:05:13 +08:00
|
|
|
#ifndef NDEBUG
|
|
|
|
if (!isa<CallInst>(I) && !isa<InvokeInst>(I) &&
|
|
|
|
I.getType() != Type::VoidTy) {
|
|
|
|
DOUT << " --> ";
|
2007-09-22 02:30:39 +08:00
|
|
|
const GenericValue &Val = SF.Values[&I];
|
|
|
|
switch (I.getType()->getTypeID()) {
|
|
|
|
default: assert(0 && "Invalid GenericValue Type");
|
|
|
|
case Type::VoidTyID: DOUT << "void"; break;
|
|
|
|
case Type::FloatTyID: DOUT << "float " << Val.FloatVal; break;
|
|
|
|
case Type::DoubleTyID: DOUT << "double " << Val.DoubleVal; break;
|
|
|
|
case Type::PointerTyID: DOUT << "void* " << intptr_t(Val.PointerVal);
|
|
|
|
break;
|
|
|
|
case Type::IntegerTyID:
|
|
|
|
DOUT << "i" << Val.IntVal.getBitWidth() << " "
|
|
|
|
<< Val.IntVal.toStringUnsigned(10)
|
|
|
|
<< " (0x" << Val.IntVal.toStringUnsigned(16) << ")\n";
|
|
|
|
break;
|
|
|
|
}
|
2007-05-16 10:05:13 +08:00
|
|
|
}
|
2007-09-22 02:30:39 +08:00
|
|
|
#endif
|
2007-05-16 10:05:13 +08:00
|
|
|
#endif
|
2001-08-24 01:05:04 +08:00
|
|
|
}
|
|
|
|
}
|