2001-08-23 17:05:04 +00:00
|
|
|
//===-- Execution.cpp - Implement code to simulate the program ------------===//
|
2005-04-21 22:43:08 +00:00
|
|
|
//
|
2003-10-20 19:43:21 +00:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file was developed by the LLVM research group and is distributed under
|
|
|
|
// the University of Illinois Open Source License. See LICENSE.TXT for details.
|
2005-04-21 22:43:08 +00:00
|
|
|
//
|
2003-10-20 19:43:21 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2005-04-21 22:43:08 +00:00
|
|
|
//
|
2001-08-23 17:05:04 +00:00
|
|
|
// This file contains the actual instruction interpreter.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2003-12-11 00:22:59 +00:00
|
|
|
#define DEBUG_TYPE "interpreter"
|
2001-08-23 17:05:04 +00:00
|
|
|
#include "Interpreter.h"
|
2002-04-28 19:55:58 +00:00
|
|
|
#include "llvm/Constants.h"
|
2003-12-28 09:44:37 +00:00
|
|
|
#include "llvm/DerivedTypes.h"
|
|
|
|
#include "llvm/Instructions.h"
|
2004-06-20 07:49:54 +00:00
|
|
|
#include "llvm/CodeGen/IntrinsicLowering.h"
|
2003-11-25 20:44:56 +00:00
|
|
|
#include "llvm/Support/GetElementPtrTypeIterator.h"
|
2007-03-03 06:22:22 +00:00
|
|
|
#include "llvm/ADT/APInt.h"
|
2004-09-01 22:55:40 +00:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
|
|
|
#include "llvm/Support/Debug.h"
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
#include "llvm/Support/MathExtras.h"
|
2006-12-02 02:22:01 +00:00
|
|
|
#include <cmath>
|
2003-11-25 20:44:56 +00:00
|
|
|
using namespace llvm;
|
2002-12-23 23:59:41 +00:00
|
|
|
|
2006-12-19 22:56:53 +00:00
|
|
|
STATISTIC(NumDynamicInsts, "Number of dynamic instructions executed");
|
|
|
|
static Interpreter *TheEE = 0;
|
2003-11-11 22:41:34 +00:00
|
|
|
|
2001-10-15 13:25:40 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2007-03-03 06:22:22 +00:00
|
|
|
// Various Helper Functions
|
2001-10-15 13:25:40 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2003-12-28 09:44:37 +00:00
|
|
|
|
2007-03-03 06:22:22 +00:00
|
|
|
static inline uint64_t doSignExtension(uint64_t Val, const IntegerType* ITy) {
|
2007-01-20 20:12:29 +00: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 13:25:40 +00:00
|
|
|
static void SetValue(Value *V, GenericValue Val, ExecutionContext &SF) {
|
2003-10-24 19:59:01 +00:00
|
|
|
SF.Values[V] = Val;
|
2001-10-15 13:25:40 +00:00
|
|
|
}
|
|
|
|
|
2001-10-15 05:51:48 +00:00
|
|
|
void Interpreter::initializeExecutionEngine() {
|
2002-12-23 23:59:41 +00:00
|
|
|
TheEE = this;
|
2001-10-15 05:51:48 +00:00
|
|
|
}
|
|
|
|
|
2001-08-23 17:05:04 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Binary Instruction Implementations
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#define IMPLEMENT_BINARY_OPERATOR(OP, TY) \
|
2007-03-06 03:09:31 +00:00
|
|
|
case Type::TY##TyID: \
|
|
|
|
Dest.TY##Val = Src1.TY##Val OP Src2.TY##Val; \
|
|
|
|
break
|
2001-08-23 17:05:04 +00:00
|
|
|
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
case Type::IntegerTyID: { \
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
break; \
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-03-03 06:22:22 +00:00
|
|
|
static void executeAddInst(GenericValue &Dest, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2007-03-06 03:09:31 +00:00
|
|
|
IMPLEMENT_INTEGER_BINOP1(+, Ty);
|
2001-08-23 17:05:04 +00:00
|
|
|
IMPLEMENT_BINARY_OPERATOR(+, Float);
|
|
|
|
IMPLEMENT_BINARY_OPERATOR(+, Double);
|
|
|
|
default:
|
2006-12-07 01:30:32 +00:00
|
|
|
cerr << "Unhandled type for Add instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-03 06:22:22 +00:00
|
|
|
static void executeSubInst(GenericValue &Dest, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2007-03-06 03:09:31 +00:00
|
|
|
IMPLEMENT_INTEGER_BINOP1(-, Ty);
|
2001-08-23 17:05:04 +00:00
|
|
|
IMPLEMENT_BINARY_OPERATOR(-, Float);
|
|
|
|
IMPLEMENT_BINARY_OPERATOR(-, Double);
|
|
|
|
default:
|
2006-12-07 01:30:32 +00:00
|
|
|
cerr << "Unhandled type for Sub instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-03 06:22:22 +00:00
|
|
|
static void executeMulInst(GenericValue &Dest, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2007-03-06 03:09:31 +00:00
|
|
|
IMPLEMENT_INTEGER_BINOP1(*, Ty);
|
2001-10-27 08:28:11 +00:00
|
|
|
IMPLEMENT_BINARY_OPERATOR(*, Float);
|
|
|
|
IMPLEMENT_BINARY_OPERATOR(*, Double);
|
|
|
|
default:
|
2006-12-07 01:30:32 +00:00
|
|
|
cerr << "Unhandled type for Mul instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-10-27 08:28:11 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-03 06:22:22 +00:00
|
|
|
static void executeFDivInst(GenericValue &Dest, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
2006-10-26 06:15:43 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2001-10-27 08:28:11 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
cerr << "Unhandled type for FDiv instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-10-30 20:27:31 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-03 06:22:22 +00:00
|
|
|
static void executeFRemInst(GenericValue &Dest, GenericValue Src1,
|
|
|
|
GenericValue Src2, const Type *Ty) {
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2001-10-30 20:27:31 +00: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 01:30:32 +00:00
|
|
|
cerr << "Unhandled type for Rem instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-10-27 08:28:11 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-03-06 03:09:31 +00:00
|
|
|
#define IMPLEMENT_INTEGER_ICMP(OP, TY) \
|
|
|
|
case Type::IntegerTyID: \
|
|
|
|
Dest.IntVal = APInt(1,Src1.IntVal.OP(Src2.IntVal)); \
|
|
|
|
break;
|
2001-08-23 17:05:04 +00:00
|
|
|
|
2003-04-23 19:55:35 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
#define IMPLEMENT_POINTER_ICMP(OP) \
|
2003-04-23 19:55:35 +00:00
|
|
|
case Type::PointerTyID: \
|
2007-03-06 03:09:31 +00:00
|
|
|
Dest.IntVal = APInt(1,(void*)(intptr_t)Src1.PointerVal OP \
|
|
|
|
(void*)(intptr_t)Src2.PointerVal); \
|
|
|
|
break;
|
2003-04-23 19:55:35 +00:00
|
|
|
|
2006-12-23 06:05:41 +00:00
|
|
|
static GenericValue executeICMP_EQ(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
switch (Ty->getTypeID()) {
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
IMPLEMENT_POINTER_ICMP(==);
|
2006-12-23 06:05:41 +00: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 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
IMPLEMENT_POINTER_ICMP(!=);
|
2006-12-23 06:05:41 +00: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 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
IMPLEMENT_POINTER_ICMP(<);
|
2006-12-23 06:05:41 +00: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 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
IMPLEMENT_POINTER_ICMP(<);
|
2006-12-23 06:05:41 +00: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 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
IMPLEMENT_POINTER_ICMP(>);
|
2006-12-23 06:05:41 +00: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 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
IMPLEMENT_POINTER_ICMP(>);
|
2006-12-23 06:05:41 +00: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 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
IMPLEMENT_POINTER_ICMP(<=);
|
2006-12-23 06:05:41 +00: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 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
IMPLEMENT_POINTER_ICMP(<=);
|
2006-12-23 06:05:41 +00: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 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
IMPLEMENT_POINTER_ICMP(>=);
|
2006-12-23 06:05:41 +00: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 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
IMPLEMENT_POINTER_ICMP(>=);
|
2006-12-23 06:05:41 +00:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled type for ICMP_SGE predicate: " << *Ty << "\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2006-12-31 05:51:36 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00: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 05:51:36 +00: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 03:09:31 +00:00
|
|
|
case Type::TY##TyID: \
|
|
|
|
Dest.IntVal = APInt(1,Src1.TY##Val OP Src2.TY##Val); \
|
|
|
|
break
|
2006-12-23 06:05:41 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
static GenericValue executeFCMP_OEQ(GenericValue Src1, GenericValue Src2,
|
2006-12-23 06:05:41 +00:00
|
|
|
const Type *Ty) {
|
2001-08-23 17:05:04 +00:00
|
|
|
GenericValue Dest;
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 05:51:36 +00:00
|
|
|
IMPLEMENT_FCMP(==, Float);
|
|
|
|
IMPLEMENT_FCMP(==, Double);
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
cerr << "Unhandled type for FCmp EQ instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
static GenericValue executeFCMP_ONE(GenericValue Src1, GenericValue Src2,
|
2006-12-23 06:05:41 +00:00
|
|
|
const Type *Ty) {
|
2001-08-23 17:05:04 +00:00
|
|
|
GenericValue Dest;
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 05:51:36 +00:00
|
|
|
IMPLEMENT_FCMP(!=, Float);
|
|
|
|
IMPLEMENT_FCMP(!=, Double);
|
2001-11-07 19:46:27 +00:00
|
|
|
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
cerr << "Unhandled type for FCmp NE instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
static GenericValue executeFCMP_OLE(GenericValue Src1, GenericValue Src2,
|
2006-12-23 06:05:41 +00:00
|
|
|
const Type *Ty) {
|
2001-08-23 17:05:04 +00:00
|
|
|
GenericValue Dest;
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 05:51:36 +00:00
|
|
|
IMPLEMENT_FCMP(<=, Float);
|
|
|
|
IMPLEMENT_FCMP(<=, Double);
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
cerr << "Unhandled type for FCmp LE instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
static GenericValue executeFCMP_OGE(GenericValue Src1, GenericValue Src2,
|
2006-12-23 06:05:41 +00:00
|
|
|
const Type *Ty) {
|
2001-08-23 17:05:04 +00:00
|
|
|
GenericValue Dest;
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 05:51:36 +00:00
|
|
|
IMPLEMENT_FCMP(>=, Float);
|
|
|
|
IMPLEMENT_FCMP(>=, Double);
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
cerr << "Unhandled type for FCmp GE instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
static GenericValue executeFCMP_OLT(GenericValue Src1, GenericValue Src2,
|
2006-12-23 06:05:41 +00:00
|
|
|
const Type *Ty) {
|
2001-08-23 17:05:04 +00:00
|
|
|
GenericValue Dest;
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 05:51:36 +00:00
|
|
|
IMPLEMENT_FCMP(<, Float);
|
|
|
|
IMPLEMENT_FCMP(<, Double);
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
cerr << "Unhandled type for FCmp LT instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
static GenericValue executeFCMP_OGT(GenericValue Src1, GenericValue Src2,
|
2005-04-21 22:43:08 +00:00
|
|
|
const Type *Ty) {
|
2001-08-23 17:05:04 +00:00
|
|
|
GenericValue Dest;
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2006-12-31 05:51:36 +00:00
|
|
|
IMPLEMENT_FCMP(>, Float);
|
|
|
|
IMPLEMENT_FCMP(>, Double);
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
cerr << "Unhandled type for FCmp GT instruction: " << *Ty << "\n";
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
#define IMPLEMENT_UNORDERED(TY, X,Y) \
|
|
|
|
if (TY == Type::FloatTy) \
|
|
|
|
if (X.FloatVal != X.FloatVal || Y.FloatVal != Y.FloatVal) { \
|
2007-03-06 03:09:31 +00:00
|
|
|
Dest.IntVal = APInt(1,true); \
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
return Dest; \
|
|
|
|
} \
|
|
|
|
else if (X.DoubleVal != X.DoubleVal || Y.DoubleVal != Y.DoubleVal) { \
|
2007-03-06 03:09:31 +00:00
|
|
|
Dest.IntVal = APInt(1,true); \
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
return Dest; \
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UEQ(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_OEQ(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UNE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_ONE(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_ULE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_OLE(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UGE(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_OGE(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_ULT(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_OLT(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UGT(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
IMPLEMENT_UNORDERED(Ty, Src1, Src2)
|
|
|
|
return executeFCMP_OGT(Src1, Src2, Ty);
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_ORD(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
if (Ty == Type::FloatTy)
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
else
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenericValue executeFCMP_UNO(GenericValue Src1, GenericValue Src2,
|
|
|
|
const Type *Ty) {
|
|
|
|
GenericValue Dest;
|
|
|
|
if (Ty == Type::FloatTy)
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
else
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
2006-12-23 06:05:41 +00: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 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00: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 06:05:41 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00: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 06:05:41 +00:00
|
|
|
case FCmpInst::FCMP_FALSE: {
|
|
|
|
GenericValue Result;
|
2007-03-06 03:09:31 +00:00
|
|
|
Result.IntVal = APInt(1, false);
|
2006-12-23 06:05:41 +00:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
case FCmpInst::FCMP_TRUE: {
|
|
|
|
GenericValue Result;
|
2007-03-06 03:09:31 +00:00
|
|
|
Result.IntVal = APInt(1, true);
|
2006-12-23 06:05:41 +00:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
cerr << "Unhandled Cmp predicate\n";
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-05-10 21:22:39 +00:00
|
|
|
void Interpreter::visitBinaryOperator(BinaryOperator &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2002-06-25 16:13:21 +00:00
|
|
|
const Type *Ty = I.getOperand(0)->getType();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
2001-08-23 17:05:04 +00:00
|
|
|
GenericValue R; // Result
|
|
|
|
|
2002-06-25 16:13:21 +00:00
|
|
|
switch (I.getOpcode()) {
|
2007-03-03 06:22:22 +00: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 03:09:31 +00: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-23 17:05:04 +00:00
|
|
|
default:
|
2006-12-07 01:30:32 +00:00
|
|
|
cerr << "Don't know how to handle this binary operator!\n-->" << I;
|
2003-04-22 21:22:33 +00:00
|
|
|
abort();
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
|
|
|
|
2002-06-25 16:13:21 +00:00
|
|
|
SetValue(&I, R, SF);
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
|
|
|
|
2005-04-21 22:43:08 +00:00
|
|
|
static GenericValue executeSelectInst(GenericValue Src1, GenericValue Src2,
|
2004-04-20 16:43:21 +00:00
|
|
|
GenericValue Src3) {
|
2007-03-06 03:09:31 +00:00
|
|
|
return Src1.IntVal == 0 ? Src3 : Src2;
|
2004-04-20 16:43:21 +00: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 03:09:31 +00:00
|
|
|
GenericValue R = executeSelectInst(Src1, Src2, Src3);
|
2004-04-20 16:43:21 +00:00
|
|
|
SetValue(&I, R, SF);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2001-08-23 17:05:04 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Terminator Instruction Implementations
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2001-10-27 04:15:57 +00:00
|
|
|
void Interpreter::exitCalled(GenericValue GV) {
|
2004-02-13 05:48:00 +00: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 00:22:59 +00:00
|
|
|
runAtExitHandlers ();
|
2007-03-06 03:09:31 +00:00
|
|
|
exit (GV.IntVal.zextOrTrunc(32).getZExtValue());
|
2001-10-27 04:15:57 +00:00
|
|
|
}
|
|
|
|
|
2003-11-07 05:22:49 +00: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 05:29:44 +00:00
|
|
|
/// result variable may be the ExitValue, or the Value of the calling
|
2003-11-07 20:44:58 +00: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 05:22:49 +00:00
|
|
|
///
|
|
|
|
void Interpreter::popStackAndReturnValueToCaller (const Type *RetTy,
|
|
|
|
GenericValue Result) {
|
|
|
|
// Pop the current stack frame.
|
|
|
|
ECStack.pop_back();
|
|
|
|
|
2005-04-21 22:43:08 +00:00
|
|
|
if (ECStack.empty()) { // Finished main. Put result into exit code...
|
2007-01-15 02:27:26 +00:00
|
|
|
if (RetTy && RetTy->isInteger()) { // Nonvoid return type?
|
2006-02-07 05:29:44 +00:00
|
|
|
ExitValue = Result; // Capture the exit value of the program
|
2005-04-21 22:43:08 +00:00
|
|
|
} else {
|
2006-02-07 05:29:44 +00:00
|
|
|
memset(&ExitValue, 0, sizeof(ExitValue));
|
2005-04-21 22:43:08 +00:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// If we have a previous stack frame, and we have a previous call,
|
|
|
|
// fill in the return value...
|
2003-11-07 05:22:49 +00:00
|
|
|
ExecutionContext &CallingSF = ECStack.back();
|
2003-11-07 20:44:58 +00:00
|
|
|
if (Instruction *I = CallingSF.Caller.getInstruction()) {
|
2003-11-07 19:26:23 +00:00
|
|
|
if (CallingSF.Caller.getType() != Type::VoidTy) // Save result...
|
2003-11-07 20:44:58 +00:00
|
|
|
SetValue(I, Result, CallingSF);
|
|
|
|
if (InvokeInst *II = dyn_cast<InvokeInst> (I))
|
|
|
|
SwitchToNewBasicBlock (II->getNormalDest (), CallingSF);
|
2003-11-07 19:26:23 +00:00
|
|
|
CallingSF.Caller = CallSite(); // We returned from the call...
|
2003-11-07 05:22:49 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-05-10 21:22:39 +00:00
|
|
|
void Interpreter::visitReturnInst(ReturnInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2003-11-07 05:22:49 +00:00
|
|
|
const Type *RetTy = Type::VoidTy;
|
2001-08-23 17:05:04 +00:00
|
|
|
GenericValue Result;
|
|
|
|
|
|
|
|
// Save away the return value... (if we are not 'ret void')
|
2002-06-25 16:13:21 +00:00
|
|
|
if (I.getNumOperands()) {
|
|
|
|
RetTy = I.getReturnValue()->getType();
|
|
|
|
Result = getOperandValue(I.getReturnValue(), SF);
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
|
|
|
|
2003-11-07 05:22:49 +00:00
|
|
|
popStackAndReturnValueToCaller(RetTy, Result);
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
|
|
|
|
2003-11-07 20:07:06 +00:00
|
|
|
void Interpreter::visitUnwindInst(UnwindInst &I) {
|
2003-11-07 20:44:58 +00: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-08 21:44:31 +00:00
|
|
|
SwitchToNewBasicBlock(cast<InvokeInst>(Inst)->getUnwindDest(), InvokingSF);
|
2003-11-07 20:07:06 +00:00
|
|
|
}
|
|
|
|
|
2004-10-16 18:21:33 +00:00
|
|
|
void Interpreter::visitUnreachableInst(UnreachableInst &I) {
|
2006-12-07 01:30:32 +00:00
|
|
|
cerr << "ERROR: Program executed an 'unreachable' instruction!\n";
|
2004-10-16 18:21:33 +00:00
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
2003-05-10 21:22:39 +00:00
|
|
|
void Interpreter::visitBranchInst(BranchInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2001-08-23 17:05:04 +00:00
|
|
|
BasicBlock *Dest;
|
|
|
|
|
2002-06-25 16:13:21 +00:00
|
|
|
Dest = I.getSuccessor(0); // Uncond branches have a fixed dest...
|
|
|
|
if (!I.isUnconditional()) {
|
|
|
|
Value *Cond = I.getCondition();
|
2007-03-06 03:09:31 +00:00
|
|
|
if (getOperandValue(Cond, SF).IntVal == 0) // If false cond...
|
2005-04-21 22:43:08 +00:00
|
|
|
Dest = I.getSuccessor(1);
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
2003-05-10 20:21:16 +00:00
|
|
|
SwitchToNewBasicBlock(Dest, SF);
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
|
|
|
|
2003-05-10 21:22:39 +00:00
|
|
|
void Interpreter::visitSwitchInst(SwitchInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2003-04-22 20:34:47 +00: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-10 20:21:16 +00:00
|
|
|
BasicBlock *Dest = 0;
|
|
|
|
for (unsigned i = 2, e = I.getNumOperands(); i != e; i += 2)
|
2007-03-06 03:09:31 +00:00
|
|
|
if (executeICMP_EQ(CondVal, getOperandValue(I.getOperand(i), SF), ElTy)
|
|
|
|
.IntVal != 0) {
|
2003-04-22 20:34:47 +00:00
|
|
|
Dest = cast<BasicBlock>(I.getOperand(i+1));
|
|
|
|
break;
|
|
|
|
}
|
2005-04-21 22:43:08 +00:00
|
|
|
|
2003-04-22 20:34:47 +00:00
|
|
|
if (!Dest) Dest = I.getDefaultDest(); // No cases matched: use default
|
2003-05-10 20:21:16 +00: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-21 22:43:08 +00:00
|
|
|
|
2003-05-10 20:21:16 +00: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-15 17:06:42 +00:00
|
|
|
for (unsigned i = 0; isa<PHINode>(SF.CurInst); ++SF.CurInst, ++i) {
|
|
|
|
PHINode *PN = cast<PHINode>(SF.CurInst);
|
2003-05-10 20:21:16 +00:00
|
|
|
SetValue(PN, ResultValues[i], SF);
|
2004-09-15 17:06:42 +00:00
|
|
|
}
|
2003-04-22 20:34:47 +00:00
|
|
|
}
|
|
|
|
|
2001-08-27 05:16:50 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Memory Instruction Implementations
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2003-05-10 21:22:39 +00:00
|
|
|
void Interpreter::visitAllocationInst(AllocationInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
|
2002-06-25 16:13:21 +00:00
|
|
|
const Type *Ty = I.getType()->getElementType(); // Type to be allocated
|
2001-08-27 05:16:50 +00:00
|
|
|
|
2002-04-28 21:57:33 +00:00
|
|
|
// Get the number of elements being allocated by the array...
|
2007-03-06 03:09:31 +00:00
|
|
|
unsigned NumElements =
|
|
|
|
getOperandValue(I.getOperand(0), SF).IntVal.getZExtValue();
|
|
|
|
|
|
|
|
unsigned TypeSize = (size_t)TD.getTypeSize(Ty);
|
|
|
|
|
|
|
|
unsigned MemToAlloc = NumElements * TypeSize;
|
2001-08-27 05:16:50 +00:00
|
|
|
|
|
|
|
// Allocate enough memory to hold the type...
|
2007-03-06 03:09:31 +00:00
|
|
|
void *Memory = malloc(MemToAlloc);
|
|
|
|
|
|
|
|
DOUT << "Allocated Type: " << *Ty << " (" << TypeSize << " bytes) x "
|
|
|
|
<< NumElements << " (Total: " << MemToAlloc << ") at "
|
|
|
|
<< unsigned(Memory) << '\n';
|
2002-02-19 18:50:09 +00:00
|
|
|
|
2002-12-23 23:59:41 +00:00
|
|
|
GenericValue Result = PTOGV(Memory);
|
2001-11-07 19:46:27 +00:00
|
|
|
assert(Result.PointerVal != 0 && "Null pointer returned by malloc!");
|
2002-06-25 16:13:21 +00:00
|
|
|
SetValue(&I, Result, SF);
|
2001-08-27 05:16:50 +00:00
|
|
|
|
2002-06-25 16:13:21 +00:00
|
|
|
if (I.getOpcode() == Instruction::Alloca)
|
2002-02-19 18:50:09 +00:00
|
|
|
ECStack.back().Allocas.add(Memory);
|
2001-08-27 05:16:50 +00:00
|
|
|
}
|
|
|
|
|
2003-05-10 21:22:39 +00:00
|
|
|
void Interpreter::visitFreeInst(FreeInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2002-06-25 16:13:21 +00:00
|
|
|
assert(isa<PointerType>(I.getOperand(0)->getType()) && "Freeing nonptr?");
|
|
|
|
GenericValue Value = getOperandValue(I.getOperand(0), SF);
|
2001-08-27 05:16:50 +00:00
|
|
|
// TODO: Check to make sure memory is allocated
|
2002-12-23 23:59:41 +00:00
|
|
|
free(GVTOP(Value)); // Free memory
|
2001-08-27 05:16:50 +00:00
|
|
|
}
|
|
|
|
|
2002-08-27 22:33:45 +00:00
|
|
|
// getElementOffset - The workhorse for getelementptr.
|
2001-10-29 19:32:19 +00:00
|
|
|
//
|
2003-11-25 20:44:56 +00:00
|
|
|
GenericValue Interpreter::executeGEPOperation(Value *Ptr, gep_type_iterator I,
|
2005-04-21 22:43:08 +00:00
|
|
|
gep_type_iterator E,
|
|
|
|
ExecutionContext &SF) {
|
2002-08-27 22:33:45 +00:00
|
|
|
assert(isa<PointerType>(Ptr->getType()) &&
|
2001-10-29 19:32:19 +00:00
|
|
|
"Cannot getElementOffset of a nonpointer type!");
|
|
|
|
|
2007-03-06 03:09:31 +00:00
|
|
|
uint64_t Total = 0;
|
2002-08-27 22:33:45 +00:00
|
|
|
|
|
|
|
for (; I != E; ++I) {
|
2003-11-25 20:44:56 +00:00
|
|
|
if (const StructType *STy = dyn_cast<StructType>(*I)) {
|
2001-11-26 18:18:18 +00:00
|
|
|
const StructLayout *SLO = TD.getStructLayout(STy);
|
2005-04-21 22:43:08 +00:00
|
|
|
|
2006-10-20 07:07:24 +00:00
|
|
|
const ConstantInt *CPU = cast<ConstantInt>(I.getOperand());
|
|
|
|
unsigned Index = unsigned(CPU->getZExtValue());
|
2005-04-21 22:43:08 +00:00
|
|
|
|
2007-03-06 03:09:31 +00:00
|
|
|
Total += SLO->getElementOffset(Index);
|
2003-11-25 20:44:56 +00:00
|
|
|
} else {
|
|
|
|
const SequentialType *ST = cast<SequentialType>(*I);
|
2003-02-25 21:14:59 +00:00
|
|
|
// Get the index number for the array... which must be long type...
|
2003-11-25 20:44:56 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
int64_t Idx;
|
|
|
|
unsigned BitWidth =
|
|
|
|
cast<IntegerType>(I.getOperand()->getType())->getBitWidth();
|
2007-01-18 01:25:42 +00:00
|
|
|
if (BitWidth == 32)
|
2007-03-06 03:09:31 +00:00
|
|
|
Idx = (int64_t)(int32_t)IdxGV.IntVal.getZExtValue();
|
2007-01-18 01:25:42 +00:00
|
|
|
else if (BitWidth == 64)
|
2007-03-06 03:09:31 +00:00
|
|
|
Idx = (int64_t)IdxGV.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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
else
|
2007-01-18 01:25:42 +00:00
|
|
|
assert(0 && "Invalid index type for getelementptr");
|
2007-03-06 03:09:31 +00:00
|
|
|
Total += TD.getTypeSize(ST->getElementType())*Idx;
|
2003-10-24 19:59:01 +00:00
|
|
|
}
|
2001-10-29 19:32:19 +00:00
|
|
|
}
|
|
|
|
|
2002-08-27 22:33:45 +00:00
|
|
|
GenericValue Result;
|
2007-03-06 03:09:31 +00:00
|
|
|
Result.PointerVal = ((char*)getOperandValue(Ptr, SF).PointerVal) + Total;
|
|
|
|
DOUT << "GEP Index " << Total << " bytes.\n";
|
2002-08-27 22:33:45 +00:00
|
|
|
return Result;
|
2001-10-29 19:32:19 +00:00
|
|
|
}
|
|
|
|
|
2003-05-10 21:22:39 +00:00
|
|
|
void Interpreter::visitGetElementPtrInst(GetElementPtrInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2002-12-23 23:59:41 +00:00
|
|
|
SetValue(&I, TheEE->executeGEPOperation(I.getPointerOperand(),
|
2003-11-25 20:44:56 +00:00
|
|
|
gep_type_begin(I), gep_type_end(I), SF), SF);
|
2001-10-29 19:32:19 +00:00
|
|
|
}
|
|
|
|
|
2003-05-10 21:22:39 +00:00
|
|
|
void Interpreter::visitLoadInst(LoadInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2002-06-25 16:13:21 +00:00
|
|
|
GenericValue SRC = getOperandValue(I.getPointerOperand(), SF);
|
2002-12-23 23:59:41 +00:00
|
|
|
GenericValue *Ptr = (GenericValue*)GVTOP(SRC);
|
2007-03-03 08:38:04 +00:00
|
|
|
GenericValue Result;
|
|
|
|
LoadValueFromMemory(Result, Ptr, I.getType());
|
2002-06-25 16:13:21 +00:00
|
|
|
SetValue(&I, Result, SF);
|
2001-08-27 05:16:50 +00:00
|
|
|
}
|
|
|
|
|
2003-05-10 21:22:39 +00:00
|
|
|
void Interpreter::visitStoreInst(StoreInst &I) {
|
|
|
|
ExecutionContext &SF = ECStack.back();
|
2002-06-25 16:13:21 +00:00
|
|
|
GenericValue Val = getOperandValue(I.getOperand(0), SF);
|
2002-10-15 20:34:05 +00:00
|
|
|
GenericValue SRC = getOperandValue(I.getPointerOperand(), SF);
|
2002-12-23 23:59:41 +00:00
|
|
|
StoreValueToMemory(Val, (GenericValue *)GVTOP(SRC),
|
2002-10-26 01:57:15 +00:00
|
|
|
I.getOperand(0)->getType());
|
2001-08-27 05:16:50 +00:00
|
|
|
}
|
|
|
|
|
2001-08-23 17:05:04 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Miscellaneous Instruction Implementations
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2003-11-07 20:04:22 +00:00
|
|
|
void Interpreter::visitCallSite(CallSite CS) {
|
2003-05-10 21:22:39 +00:00
|
|
|
ExecutionContext &SF = ECStack.back();
|
2003-12-28 09:44:37 +00:00
|
|
|
|
|
|
|
// Check to see if this is an intrinsic function call...
|
|
|
|
if (Function *F = CS.getCalledFunction())
|
2007-01-30 20:08:39 +00:00
|
|
|
if (F->isDeclaration ())
|
2003-12-28 09:44:37 +00:00
|
|
|
switch (F->getIntrinsicID()) {
|
2004-01-14 06:02:53 +00:00
|
|
|
case Intrinsic::not_intrinsic:
|
|
|
|
break;
|
2004-03-13 00:24:00 +00:00
|
|
|
case Intrinsic::vastart: { // va_start
|
2004-02-25 23:01:48 +00:00
|
|
|
GenericValue ArgIndex;
|
|
|
|
ArgIndex.UIntPairVal.first = ECStack.size() - 1;
|
|
|
|
ArgIndex.UIntPairVal.second = 0;
|
|
|
|
SetValue(CS.getInstruction(), ArgIndex, SF);
|
2003-12-28 09:44:37 +00:00
|
|
|
return;
|
2004-02-25 23:01:48 +00:00
|
|
|
}
|
2004-03-13 00:24:00 +00:00
|
|
|
case Intrinsic::vaend: // va_end is a noop for the interpreter
|
2003-12-28 09:44:37 +00:00
|
|
|
return;
|
2004-03-13 00:24:00 +00:00
|
|
|
case Intrinsic::vacopy: // va_copy: dest = src
|
2003-12-28 09:44:37 +00:00
|
|
|
SetValue(CS.getInstruction(), getOperandValue(*CS.arg_begin(), SF), SF);
|
|
|
|
return;
|
|
|
|
default:
|
2004-01-14 06:02:53 +00:00
|
|
|
// If it is an unknown intrinsic function, use the intrinsic lowering
|
2003-12-28 09:44:37 +00:00
|
|
|
// class to transform it into hopefully tasty LLVM code.
|
|
|
|
//
|
|
|
|
Instruction *Prev = CS.getInstruction()->getPrev();
|
|
|
|
BasicBlock *Parent = CS.getInstruction()->getParent();
|
|
|
|
IL->LowerIntrinsicCall(cast<CallInst>(CS.getInstruction()));
|
|
|
|
|
|
|
|
// Restore the CurInst pointer to the first instruction newly inserted, if
|
|
|
|
// any.
|
|
|
|
if (!Prev) {
|
|
|
|
SF.CurInst = Parent->begin();
|
|
|
|
} else {
|
|
|
|
SF.CurInst = Prev;
|
|
|
|
++SF.CurInst;
|
|
|
|
}
|
2004-04-23 18:05:28 +00:00
|
|
|
return;
|
2003-12-28 09:44:37 +00:00
|
|
|
}
|
|
|
|
|
2003-11-07 20:04:22 +00:00
|
|
|
SF.Caller = CS;
|
2003-04-22 21:22:33 +00:00
|
|
|
std::vector<GenericValue> ArgVals;
|
2003-11-07 19:59:08 +00:00
|
|
|
const unsigned NumArgs = SF.Caller.arg_size();
|
|
|
|
ArgVals.reserve(NumArgs);
|
|
|
|
for (CallSite::arg_iterator i = SF.Caller.arg_begin(),
|
|
|
|
e = SF.Caller.arg_end(); i != e; ++i) {
|
|
|
|
Value *V = *i;
|
|
|
|
ArgVals.push_back(getOperandValue(V, SF));
|
2003-01-13 00:58:52 +00:00
|
|
|
// Promote all integral types whose size is < sizeof(int) into ints. We do
|
|
|
|
// this by zero or sign extending the value as appropriate according to the
|
|
|
|
// source type.
|
2003-11-07 19:59:08 +00:00
|
|
|
const Type *Ty = V->getType();
|
2007-03-06 03:09:31 +00:00
|
|
|
if (Ty->isInteger())
|
|
|
|
if (ArgVals.back().IntVal.getBitWidth() < 32)
|
|
|
|
ArgVals.back().IntVal = ArgVals.back().IntVal.sext(32);
|
2003-01-13 00:58:52 +00:00
|
|
|
}
|
2001-09-10 04:49:44 +00:00
|
|
|
|
2005-04-21 22:43:08 +00:00
|
|
|
// To handle indirect calls, we must get the pointer value from the argument
|
2002-04-07 20:49:59 +00:00
|
|
|
// and treat it as a function pointer.
|
2005-04-21 22:43:08 +00:00
|
|
|
GenericValue SRC = getOperandValue(SF.Caller.getCalledValue(), SF);
|
2003-05-08 16:18:31 +00:00
|
|
|
callFunction((Function*)GVTOP(SRC), ArgVals);
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
|
|
|
|
2007-02-02 02:16:23 +00:00
|
|
|
void Interpreter::visitShl(BinaryOperator &I) {
|
2003-12-11 00:22:59 +00:00
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
|
|
|
GenericValue Dest;
|
2007-03-06 03:09:31 +00:00
|
|
|
Dest.IntVal = Src1.IntVal.shl(Src2.IntVal.getZExtValue());
|
2003-12-11 00:22:59 +00:00
|
|
|
SetValue(&I, Dest, SF);
|
|
|
|
}
|
|
|
|
|
2007-02-02 02:16:23 +00:00
|
|
|
void Interpreter::visitLShr(BinaryOperator &I) {
|
2006-11-08 06:47:33 +00:00
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
|
|
|
GenericValue Dest;
|
2007-03-06 03:09:31 +00:00
|
|
|
Dest.IntVal = Src1.IntVal.lshr(Src2.IntVal.getZExtValue());
|
2006-11-08 06:47:33 +00:00
|
|
|
SetValue(&I, Dest, SF);
|
|
|
|
}
|
|
|
|
|
2007-02-02 02:16:23 +00:00
|
|
|
void Interpreter::visitAShr(BinaryOperator &I) {
|
2003-12-11 00:22:59 +00:00
|
|
|
ExecutionContext &SF = ECStack.back();
|
|
|
|
GenericValue Src1 = getOperandValue(I.getOperand(0), SF);
|
|
|
|
GenericValue Src2 = getOperandValue(I.getOperand(1), SF);
|
2007-03-06 03:09:31 +00:00
|
|
|
GenericValue Dest;
|
|
|
|
Dest.IntVal = Src1.IntVal.ashr(Src2.IntVal.getZExtValue());
|
2002-06-25 16:13:21 +00:00
|
|
|
SetValue(&I, Dest, SF);
|
2001-08-27 05:16:50 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
GenericValue Interpreter::executeTruncInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
const IntegerType *SITy = cast<IntegerType>(SrcTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
|
|
|
unsigned SBitWidth = SITy->getBitWidth();
|
|
|
|
assert(SBitWidth > DBitWidth && "Invalid truncate");
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
return Dest;
|
|
|
|
}
|
2001-08-27 05:16:50 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
GenericValue Interpreter::executeSExtInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
2002-08-27 22:33:45 +00:00
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
const IntegerType *SITy = cast<IntegerType>(SrcTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
|
|
|
unsigned SBitWidth = SITy->getBitWidth();
|
|
|
|
assert(SBitWidth < DBitWidth && "Invalid sign extend");
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
return Dest;
|
|
|
|
}
|
2001-08-27 05:16:50 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
GenericValue Interpreter::executeZExtInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
const IntegerType *DITy = cast<IntegerType>(DstTy);
|
|
|
|
const IntegerType *SITy = cast<IntegerType>(SrcTy);
|
|
|
|
unsigned DBitWidth = DITy->getBitWidth();
|
|
|
|
unsigned SBitWidth = SITy->getBitWidth();
|
|
|
|
assert(SBitWidth < DBitWidth && "Invalid sign extend");
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
return Dest;
|
|
|
|
}
|
2002-08-27 22:33:45 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
GenericValue Interpreter::executeFPTruncInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(SrcTy == Type::DoubleTy && DstTy == Type::FloatTy &&
|
|
|
|
"Invalid FPTrunc instruction");
|
|
|
|
Dest.FloatVal = (float) Src.DoubleVal;
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeFPExtInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(SrcTy == Type::FloatTy && DstTy == Type::DoubleTy &&
|
|
|
|
"Invalid FPTrunc instruction");
|
|
|
|
Dest.DoubleVal = (double) Src.FloatVal;
|
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeFPToUIInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(SrcTy->isFloatingPoint() && "Invalid FPToUI instruction");
|
2007-03-03 08:38:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
if (SrcTy->getTypeID() == Type::FloatTyID)
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
else
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeFPToSIInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(SrcTy->isFloatingPoint() && "Invalid FPToSI instruction");
|
2007-03-03 08:38:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
if (SrcTy->getTypeID() == Type::FloatTyID)
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
else
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00: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 08:38:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
if (DstTy->getTypeID() == Type::FloatTyID)
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
else
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
return Dest;
|
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executeSIToFPInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
2007-01-21 00:29:26 +00:00
|
|
|
assert(DstTy->isFloatingPoint() && "Invalid SIToFP instruction");
|
2007-03-03 08:38:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
if (DstTy->getTypeID() == Type::FloatTyID)
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
else
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
return Dest;
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
GenericValue Interpreter::executePtrToIntInst(Value *SrcVal, const Type *DstTy,
|
|
|
|
ExecutionContext &SF) {
|
|
|
|
const Type *SrcTy = SrcVal->getType();
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
GenericValue Dest, Src = getOperandValue(SrcVal, SF);
|
|
|
|
assert(isa<PointerType>(SrcTy) && "Invalid PtrToInt instruction");
|
2007-03-03 08:38:04 +00:00
|
|
|
|
2007-03-06 03:09:31 +00:00
|
|
|
Dest.IntVal = APInt(DBitWidth, (intptr_t) Src.PointerVal);
|
2002-08-27 22:33:45 +00:00
|
|
|
return Dest;
|
2001-08-27 05:16:50 +00:00
|
|
|
}
|
2001-08-23 17:05:04 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00: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 08:38:04 +00:00
|
|
|
|
2007-03-06 03:46:41 +00:00
|
|
|
uint32_t PtrSize = TD.getPointerSizeInBits();
|
2007-03-06 03:41:50 +00:00
|
|
|
if (PtrSize != Src.IntVal.getBitWidth())
|
2007-03-06 03:46:41 +00:00
|
|
|
Src.IntVal = Src.IntVal.zextOrTrunc(PtrSize);
|
2007-03-06 03:41:50 +00:00
|
|
|
|
|
|
|
Dest.PointerVal = (PointerTy) 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00: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 02:27:26 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
if (SrcTy == Type::FloatTy) {
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
} else if (SrcTy == Type::DoubleTy) {
|
2007-03-06 03:09:31 +00:00
|
|
|
Dest.IntVal.doubleToBits(Src.DoubleVal);
|
2007-01-15 02:27:26 +00:00
|
|
|
} else if (SrcTy->isInteger()) {
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
} else
|
|
|
|
assert(0 && "Invalid BitCast");
|
|
|
|
} else if (DstTy == Type::FloatTy) {
|
2007-01-15 02:27:26 +00:00
|
|
|
if (SrcTy->isInteger())
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00:00
|
|
|
else
|
|
|
|
Dest.FloatVal = Src.FloatVal;
|
|
|
|
} else if (DstTy == Type::DoubleTy) {
|
2007-01-15 02:27:26 +00:00
|
|
|
if (SrcTy->isInteger())
|
2007-03-06 03:09:31 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00: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-10 21:22:39 +00: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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33113 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-12 07:05:14 +00: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-27 22:33:45 +00:00
|
|
|
}
|
2001-08-23 17:05:04 +00:00
|
|
|
|
2003-11-07 21:20:47 +00: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-25 23:01:48 +00:00
|
|
|
// Get the incoming valist parameter. LLI treats the valist as a
|
|
|
|
// (ec-stack-depth var-arg-index) pair.
|
2003-11-07 21:20:47 +00:00
|
|
|
GenericValue VAList = getOperandValue(I.getOperand(0), SF);
|
2004-02-25 23:01:48 +00:00
|
|
|
GenericValue Dest;
|
|
|
|
GenericValue Src = ECStack[VAList.UIntPairVal.first]
|
2007-03-06 03:09:31 +00:00
|
|
|
.VarArgs[VAList.UIntPairVal.second];
|
2003-11-07 21:20:47 +00:00
|
|
|
const Type *Ty = I.getType();
|
2004-06-17 18:19:28 +00:00
|
|
|
switch (Ty->getTypeID()) {
|
2007-03-06 03:09:31 +00:00
|
|
|
case Type::IntegerTyID: Dest.IntVal = Src.IntVal;
|
2003-11-07 21:20:47 +00:00
|
|
|
IMPLEMENT_VAARG(Pointer);
|
|
|
|
IMPLEMENT_VAARG(Float);
|
|
|
|
IMPLEMENT_VAARG(Double);
|
|
|
|
default:
|
2006-12-07 01:30:32 +00:00
|
|
|
cerr << "Unhandled dest type for vaarg instruction: " << *Ty << "\n";
|
2003-11-07 21:20:47 +00:00
|
|
|
abort();
|
|
|
|
}
|
2005-04-21 22:43:08 +00:00
|
|
|
|
2003-11-07 21:20:47 +00:00
|
|
|
// Set the Value of this Instruction.
|
|
|
|
SetValue(&I, Dest, SF);
|
2005-06-18 18:34:52 +00:00
|
|
|
|
|
|
|
// Move the pointer to the next vararg.
|
|
|
|
++VAList.UIntPairVal.second;
|
2003-11-07 21:20:47 +00:00
|
|
|
}
|
|
|
|
|
2007-03-03 06:22:22 +00: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 08:38:04 +00: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 06:22:22 +00:00
|
|
|
default :
|
|
|
|
break;
|
|
|
|
}
|
2007-03-03 08:38:04 +00: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 03:09:31 +00:00
|
|
|
GenericValue Op0 = getOperandValue(CE->getOperand(0), SF);
|
|
|
|
GenericValue Op1 = getOperandValue(CE->getOperand(1), SF);
|
2007-03-03 06:22:22 +00:00
|
|
|
GenericValue Dest;
|
2007-03-06 03:09:31 +00:00
|
|
|
const Type * Ty = CE->getOperand(0)->getType();
|
2007-03-03 06:22:22 +00:00
|
|
|
switch (CE->getOpcode()) {
|
2007-03-06 03:09:31 +00: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 06:22:22 +00:00
|
|
|
default:
|
|
|
|
cerr << "Unhandled ConstantExpr: " << *CE << "\n";
|
|
|
|
abort();
|
|
|
|
return GenericValue();
|
|
|
|
}
|
2007-03-03 08:38:04 +00:00
|
|
|
return Dest;
|
2007-03-03 06:22:22 +00: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-23 17:05:04 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Dispatch and Execution Code
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
2003-05-08 16:18:31 +00:00
|
|
|
// callFunction - Execute the specified function...
|
2001-08-23 17:05:04 +00:00
|
|
|
//
|
2003-05-08 16:18:31 +00:00
|
|
|
void Interpreter::callFunction(Function *F,
|
|
|
|
const std::vector<GenericValue> &ArgVals) {
|
2005-04-21 22:43:08 +00: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-17 17:26:22 +00:00
|
|
|
// Make a new stack frame... and fill it in.
|
|
|
|
ECStack.push_back(ExecutionContext());
|
|
|
|
ExecutionContext &StackFrame = ECStack.back();
|
2003-05-08 16:18:31 +00:00
|
|
|
StackFrame.CurFunction = F;
|
2003-11-07 05:22:49 +00:00
|
|
|
|
|
|
|
// Special handling for external functions.
|
2007-01-30 20:08:39 +00:00
|
|
|
if (F->isDeclaration()) {
|
2003-11-07 05:22:49 +00: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-08 16:06:52 +00:00
|
|
|
StackFrame.CurBB = F->begin();
|
2001-08-23 17:05:04 +00:00
|
|
|
StackFrame.CurInst = StackFrame.CurBB->begin();
|
2001-09-10 04:49:44 +00:00
|
|
|
|
2002-04-07 20:49:59 +00:00
|
|
|
// Run through the function arguments and initialize their values...
|
2005-03-15 04:54:21 +00:00
|
|
|
assert((ArgVals.size() == F->arg_size() ||
|
2005-04-21 22:43:08 +00:00
|
|
|
(ArgVals.size() > F->arg_size() && F->getFunctionType()->isVarArg()))&&
|
2002-04-07 20:49:59 +00:00
|
|
|
"Invalid number of values passed to function invocation!");
|
2003-05-08 16:06:52 +00:00
|
|
|
|
|
|
|
// Handle non-varargs arguments...
|
2001-09-10 04:49:44 +00:00
|
|
|
unsigned i = 0;
|
2005-03-15 04:54:21 +00:00
|
|
|
for (Function::arg_iterator AI = F->arg_begin(), E = F->arg_end(); AI != E; ++AI, ++i)
|
2002-06-25 16:13:21 +00:00
|
|
|
SetValue(AI, ArgVals[i], StackFrame);
|
2003-05-08 16:06:52 +00:00
|
|
|
|
|
|
|
// Handle varargs arguments...
|
|
|
|
StackFrame.VarArgs.assign(ArgVals.begin()+i, ArgVals.end());
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Interpreter::run() {
|
2003-09-04 23:15:40 +00:00
|
|
|
while (!ECStack.empty()) {
|
2003-10-24 19:59:01 +00:00
|
|
|
// Interpret a single instruction & increment the "PC".
|
|
|
|
ExecutionContext &SF = ECStack.back(); // Current stack frame
|
|
|
|
Instruction &I = *SF.CurInst++; // Increment before execute
|
2005-04-21 22:43:08 +00:00
|
|
|
|
2003-10-24 19:59:01 +00:00
|
|
|
// Track the number of dynamic instructions executed.
|
|
|
|
++NumDynamicInsts;
|
2001-08-23 17:05:04 +00:00
|
|
|
|
2006-11-27 23:54:50 +00:00
|
|
|
DOUT << "About to interpret: " << I;
|
2003-10-24 19:59:01 +00:00
|
|
|
visit(I); // Dispatch to one of the visit* methods...
|
2001-08-23 17:05:04 +00:00
|
|
|
}
|
|
|
|
}
|