2003-09-30 20:37:50 +02:00
|
|
|
//===-- llvm/User.h - User class definition ---------------------*- C++ -*-===//
|
2005-04-21 22:19:05 +02:00
|
|
|
//
|
2003-10-20 22:19:47 +02: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:19:05 +02:00
|
|
|
//
|
2003-10-20 22:19:47 +02:00
|
|
|
//===----------------------------------------------------------------------===//
|
2001-06-06 22:29:01 +02:00
|
|
|
//
|
|
|
|
// This class defines the interface that one who 'use's a Value must implement.
|
|
|
|
// Each instance of the Value class keeps track of what User's have handles
|
|
|
|
// to it.
|
|
|
|
//
|
|
|
|
// * Instructions are the largest class of User's.
|
|
|
|
// * Constants may be users of other constants (think arrays and stuff)
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_USER_H
|
|
|
|
#define LLVM_USER_H
|
|
|
|
|
|
|
|
#include "llvm/Value.h"
|
2003-10-16 00:09:57 +02:00
|
|
|
#include <vector>
|
2001-06-06 22:29:01 +02:00
|
|
|
|
2003-11-11 23:41:34 +01:00
|
|
|
namespace llvm {
|
|
|
|
|
2001-06-06 22:29:01 +02:00
|
|
|
class User : public Value {
|
|
|
|
User(const User &); // Do not implement
|
2001-07-07 10:36:50 +02:00
|
|
|
protected:
|
Instead of storing operands as std::vector<Use>, just maintain a pointer
and num operands in the User class. this allows us to embed the operands
directly in the subclasses if possible. For example, for binary operators
we store the two operands in the derived class.
The has several effects:
1. it improves locality because the operands and instruction are together
2. it makes accesses to operands faster (one less load) if you access them
through the derived class pointer. For example this:
Value *GetBinaryOperatorOp(BinaryOperator *I, int i) {
return I->getOperand(i);
}
Was compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 4(%esp), %edx
movl 8(%esp), %eax
sall $4, %eax
movl 24(%edx), %ecx
addl %ecx, %eax
movl (%eax), %eax
ret
and is now compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 8(%esp), %eax
movl 4(%esp), %edx
sall $4, %eax
addl %edx, %eax
movl 44(%eax), %eax
ret
Accesses through "Instruction*" are unmodified.
3. This reduces memory consumption (by about 3%) by eliminating 1 word of
vector overhead and a malloc header on a seperate object.
4. This speeds up gccas about 10% (both debug and release builds) on
large things (such as 176.gcc). For example, it takes a debug build
from 172.9 -> 155.6s and a release gccas from 67.7 -> 61.8s
llvm-svn: 19883
2005-01-29 01:29:39 +01:00
|
|
|
/// OperandList - This is a pointer to the array of Users for this operand.
|
|
|
|
/// For nodes of fixed arity (e.g. a binary operator) this array will live
|
|
|
|
/// embedded into the derived class. For nodes of variable arity
|
|
|
|
/// (e.g. ConstantArrays, CallInst, PHINodes, etc), this memory will be
|
|
|
|
/// dynamically allocated and should be destroyed by the classes virtual dtor.
|
|
|
|
Use *OperandList;
|
|
|
|
|
|
|
|
/// NumOperands - The number of values used by this User.
|
|
|
|
///
|
|
|
|
unsigned NumOperands;
|
|
|
|
|
2001-06-06 22:29:01 +02:00
|
|
|
public:
|
2005-04-21 22:19:05 +02:00
|
|
|
User(const Type *Ty, unsigned vty, Use *OpList, unsigned NumOps,
|
Instead of storing operands as std::vector<Use>, just maintain a pointer
and num operands in the User class. this allows us to embed the operands
directly in the subclasses if possible. For example, for binary operators
we store the two operands in the derived class.
The has several effects:
1. it improves locality because the operands and instruction are together
2. it makes accesses to operands faster (one less load) if you access them
through the derived class pointer. For example this:
Value *GetBinaryOperatorOp(BinaryOperator *I, int i) {
return I->getOperand(i);
}
Was compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 4(%esp), %edx
movl 8(%esp), %eax
sall $4, %eax
movl 24(%edx), %ecx
addl %ecx, %eax
movl (%eax), %eax
ret
and is now compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 8(%esp), %eax
movl 4(%esp), %edx
sall $4, %eax
addl %edx, %eax
movl 44(%eax), %eax
ret
Accesses through "Instruction*" are unmodified.
3. This reduces memory consumption (by about 3%) by eliminating 1 word of
vector overhead and a malloc header on a seperate object.
4. This speeds up gccas about 10% (both debug and release builds) on
large things (such as 176.gcc). For example, it takes a debug build
from 172.9 -> 155.6s and a release gccas from 67.7 -> 61.8s
llvm-svn: 19883
2005-01-29 01:29:39 +01:00
|
|
|
const std::string &name = "")
|
|
|
|
: Value(Ty, vty, name), OperandList(OpList), NumOperands(NumOps) {}
|
2001-06-06 22:29:01 +02:00
|
|
|
|
2005-04-21 22:19:05 +02:00
|
|
|
Value *getOperand(unsigned i) const {
|
Instead of storing operands as std::vector<Use>, just maintain a pointer
and num operands in the User class. this allows us to embed the operands
directly in the subclasses if possible. For example, for binary operators
we store the two operands in the derived class.
The has several effects:
1. it improves locality because the operands and instruction are together
2. it makes accesses to operands faster (one less load) if you access them
through the derived class pointer. For example this:
Value *GetBinaryOperatorOp(BinaryOperator *I, int i) {
return I->getOperand(i);
}
Was compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 4(%esp), %edx
movl 8(%esp), %eax
sall $4, %eax
movl 24(%edx), %ecx
addl %ecx, %eax
movl (%eax), %eax
ret
and is now compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 8(%esp), %eax
movl 4(%esp), %edx
sall $4, %eax
addl %edx, %eax
movl 44(%eax), %eax
ret
Accesses through "Instruction*" are unmodified.
3. This reduces memory consumption (by about 3%) by eliminating 1 word of
vector overhead and a malloc header on a seperate object.
4. This speeds up gccas about 10% (both debug and release builds) on
large things (such as 176.gcc). For example, it takes a debug build
from 172.9 -> 155.6s and a release gccas from 67.7 -> 61.8s
llvm-svn: 19883
2005-01-29 01:29:39 +01:00
|
|
|
assert(i < NumOperands && "getOperand() out of range!");
|
|
|
|
return OperandList[i];
|
2001-07-07 10:36:50 +02:00
|
|
|
}
|
Instead of storing operands as std::vector<Use>, just maintain a pointer
and num operands in the User class. this allows us to embed the operands
directly in the subclasses if possible. For example, for binary operators
we store the two operands in the derived class.
The has several effects:
1. it improves locality because the operands and instruction are together
2. it makes accesses to operands faster (one less load) if you access them
through the derived class pointer. For example this:
Value *GetBinaryOperatorOp(BinaryOperator *I, int i) {
return I->getOperand(i);
}
Was compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 4(%esp), %edx
movl 8(%esp), %eax
sall $4, %eax
movl 24(%edx), %ecx
addl %ecx, %eax
movl (%eax), %eax
ret
and is now compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 8(%esp), %eax
movl 4(%esp), %edx
sall $4, %eax
addl %edx, %eax
movl 44(%eax), %eax
ret
Accesses through "Instruction*" are unmodified.
3. This reduces memory consumption (by about 3%) by eliminating 1 word of
vector overhead and a malloc header on a seperate object.
4. This speeds up gccas about 10% (both debug and release builds) on
large things (such as 176.gcc). For example, it takes a debug build
from 172.9 -> 155.6s and a release gccas from 67.7 -> 61.8s
llvm-svn: 19883
2005-01-29 01:29:39 +01:00
|
|
|
void setOperand(unsigned i, Value *Val) {
|
|
|
|
assert(i < NumOperands && "setOperand() out of range!");
|
|
|
|
OperandList[i] = Val;
|
2001-07-07 10:36:50 +02:00
|
|
|
}
|
Instead of storing operands as std::vector<Use>, just maintain a pointer
and num operands in the User class. this allows us to embed the operands
directly in the subclasses if possible. For example, for binary operators
we store the two operands in the derived class.
The has several effects:
1. it improves locality because the operands and instruction are together
2. it makes accesses to operands faster (one less load) if you access them
through the derived class pointer. For example this:
Value *GetBinaryOperatorOp(BinaryOperator *I, int i) {
return I->getOperand(i);
}
Was compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 4(%esp), %edx
movl 8(%esp), %eax
sall $4, %eax
movl 24(%edx), %ecx
addl %ecx, %eax
movl (%eax), %eax
ret
and is now compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 8(%esp), %eax
movl 4(%esp), %edx
sall $4, %eax
addl %edx, %eax
movl 44(%eax), %eax
ret
Accesses through "Instruction*" are unmodified.
3. This reduces memory consumption (by about 3%) by eliminating 1 word of
vector overhead and a malloc header on a seperate object.
4. This speeds up gccas about 10% (both debug and release builds) on
large things (such as 176.gcc). For example, it takes a debug build
from 172.9 -> 155.6s and a release gccas from 67.7 -> 61.8s
llvm-svn: 19883
2005-01-29 01:29:39 +01:00
|
|
|
unsigned getNumOperands() const { return NumOperands; }
|
2001-07-07 10:36:50 +02:00
|
|
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
// Operand Iterator interface...
|
2001-06-06 22:29:01 +02:00
|
|
|
//
|
Instead of storing operands as std::vector<Use>, just maintain a pointer
and num operands in the User class. this allows us to embed the operands
directly in the subclasses if possible. For example, for binary operators
we store the two operands in the derived class.
The has several effects:
1. it improves locality because the operands and instruction are together
2. it makes accesses to operands faster (one less load) if you access them
through the derived class pointer. For example this:
Value *GetBinaryOperatorOp(BinaryOperator *I, int i) {
return I->getOperand(i);
}
Was compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 4(%esp), %edx
movl 8(%esp), %eax
sall $4, %eax
movl 24(%edx), %ecx
addl %ecx, %eax
movl (%eax), %eax
ret
and is now compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 8(%esp), %eax
movl 4(%esp), %edx
sall $4, %eax
addl %edx, %eax
movl 44(%eax), %eax
ret
Accesses through "Instruction*" are unmodified.
3. This reduces memory consumption (by about 3%) by eliminating 1 word of
vector overhead and a malloc header on a seperate object.
4. This speeds up gccas about 10% (both debug and release builds) on
large things (such as 176.gcc). For example, it takes a debug build
from 172.9 -> 155.6s and a release gccas from 67.7 -> 61.8s
llvm-svn: 19883
2005-01-29 01:29:39 +01:00
|
|
|
typedef Use* op_iterator;
|
|
|
|
typedef const Use* const_op_iterator;
|
2001-07-07 10:36:50 +02:00
|
|
|
|
Instead of storing operands as std::vector<Use>, just maintain a pointer
and num operands in the User class. this allows us to embed the operands
directly in the subclasses if possible. For example, for binary operators
we store the two operands in the derived class.
The has several effects:
1. it improves locality because the operands and instruction are together
2. it makes accesses to operands faster (one less load) if you access them
through the derived class pointer. For example this:
Value *GetBinaryOperatorOp(BinaryOperator *I, int i) {
return I->getOperand(i);
}
Was compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 4(%esp), %edx
movl 8(%esp), %eax
sall $4, %eax
movl 24(%edx), %ecx
addl %ecx, %eax
movl (%eax), %eax
ret
and is now compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 8(%esp), %eax
movl 4(%esp), %edx
sall $4, %eax
addl %edx, %eax
movl 44(%eax), %eax
ret
Accesses through "Instruction*" are unmodified.
3. This reduces memory consumption (by about 3%) by eliminating 1 word of
vector overhead and a malloc header on a seperate object.
4. This speeds up gccas about 10% (both debug and release builds) on
large things (such as 176.gcc). For example, it takes a debug build
from 172.9 -> 155.6s and a release gccas from 67.7 -> 61.8s
llvm-svn: 19883
2005-01-29 01:29:39 +01:00
|
|
|
inline op_iterator op_begin() { return OperandList; }
|
|
|
|
inline const_op_iterator op_begin() const { return OperandList; }
|
|
|
|
inline op_iterator op_end() { return OperandList+NumOperands; }
|
|
|
|
inline const_op_iterator op_end() const { return OperandList+NumOperands; }
|
2003-06-18 00:15:55 +02:00
|
|
|
|
2001-07-07 21:00:36 +02:00
|
|
|
// dropAllReferences() - This function is in charge of "letting go" of all
|
|
|
|
// objects that this User refers to. This allows one to
|
2001-06-06 22:29:01 +02:00
|
|
|
// 'delete' a whole class at a time, even though there may be circular
|
|
|
|
// references... first all references are dropped, and all use counts go to
|
|
|
|
// zero. Then everything is delete'd for real. Note that no operations are
|
2005-04-21 22:19:05 +02:00
|
|
|
// valid on an object that has "dropped all references", except operator
|
2001-06-06 22:29:01 +02:00
|
|
|
// delete.
|
|
|
|
//
|
Instead of storing operands as std::vector<Use>, just maintain a pointer
and num operands in the User class. this allows us to embed the operands
directly in the subclasses if possible. For example, for binary operators
we store the two operands in the derived class.
The has several effects:
1. it improves locality because the operands and instruction are together
2. it makes accesses to operands faster (one less load) if you access them
through the derived class pointer. For example this:
Value *GetBinaryOperatorOp(BinaryOperator *I, int i) {
return I->getOperand(i);
}
Was compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 4(%esp), %edx
movl 8(%esp), %eax
sall $4, %eax
movl 24(%edx), %ecx
addl %ecx, %eax
movl (%eax), %eax
ret
and is now compiled to:
_Z19GetBinaryOperatorOpPN4llvm14BinaryOperatorEi:
movl 8(%esp), %eax
movl 4(%esp), %edx
sall $4, %eax
addl %edx, %eax
movl 44(%eax), %eax
ret
Accesses through "Instruction*" are unmodified.
3. This reduces memory consumption (by about 3%) by eliminating 1 word of
vector overhead and a malloc header on a seperate object.
4. This speeds up gccas about 10% (both debug and release builds) on
large things (such as 176.gcc). For example, it takes a debug build
from 172.9 -> 155.6s and a release gccas from 67.7 -> 61.8s
llvm-svn: 19883
2005-01-29 01:29:39 +01:00
|
|
|
void dropAllReferences() {
|
|
|
|
Use *OL = OperandList;
|
|
|
|
for (unsigned i = 0, e = NumOperands; i != e; ++i)
|
|
|
|
OL[i].set(0);
|
2001-07-07 10:36:50 +02:00
|
|
|
}
|
2001-06-06 22:29:01 +02:00
|
|
|
|
2002-08-26 00:54:55 +02:00
|
|
|
/// replaceUsesOfWith - Replaces all references to the "From" definition with
|
|
|
|
/// references to the "To" definition.
|
|
|
|
///
|
2001-06-06 22:29:01 +02:00
|
|
|
void replaceUsesOfWith(Value *From, Value *To);
|
2001-07-08 20:38:18 +02:00
|
|
|
|
2001-10-13 08:18:05 +02:00
|
|
|
// Methods for support type inquiry through isa, cast, and dyn_cast:
|
|
|
|
static inline bool classof(const User *) { return true; }
|
|
|
|
static inline bool classof(const Value *V) {
|
2004-07-18 01:32:11 +02:00
|
|
|
return isa<Instruction>(V) || isa<Constant>(V);
|
2001-10-13 08:18:05 +02:00
|
|
|
}
|
2001-06-06 22:29:01 +02:00
|
|
|
};
|
|
|
|
|
2003-05-29 17:08:33 +02:00
|
|
|
template<> struct simplify_type<User::op_iterator> {
|
|
|
|
typedef Value* SimpleType;
|
2005-04-21 22:19:05 +02:00
|
|
|
|
2003-05-29 17:08:33 +02:00
|
|
|
static SimpleType getSimplifiedValue(const User::op_iterator &Val) {
|
2003-11-16 21:21:15 +01:00
|
|
|
return static_cast<SimpleType>(Val->get());
|
2003-05-29 17:08:33 +02:00
|
|
|
}
|
|
|
|
};
|
2005-02-27 07:15:51 +01:00
|
|
|
|
2003-05-29 17:08:33 +02:00
|
|
|
template<> struct simplify_type<const User::op_iterator>
|
|
|
|
: public simplify_type<User::op_iterator> {};
|
|
|
|
|
|
|
|
template<> struct simplify_type<User::const_op_iterator> {
|
|
|
|
typedef Value* SimpleType;
|
2005-04-21 22:19:05 +02:00
|
|
|
|
2003-05-29 17:08:33 +02:00
|
|
|
static SimpleType getSimplifiedValue(const User::const_op_iterator &Val) {
|
2003-11-16 21:21:15 +01:00
|
|
|
return static_cast<SimpleType>(Val->get());
|
2003-05-29 17:08:33 +02:00
|
|
|
}
|
|
|
|
};
|
2005-02-27 07:15:51 +01:00
|
|
|
|
2003-05-29 17:08:33 +02:00
|
|
|
template<> struct simplify_type<const User::const_op_iterator>
|
|
|
|
: public simplify_type<User::const_op_iterator> {};
|
|
|
|
|
2006-05-08 07:59:36 +02:00
|
|
|
|
|
|
|
// value_use_iterator::getOperandNo - Requires the definition of the User class.
|
|
|
|
template<typename UserTy>
|
|
|
|
unsigned value_use_iterator<UserTy>::getOperandNo() const {
|
|
|
|
return U - U->getUser()->op_begin();
|
|
|
|
}
|
|
|
|
|
2003-11-11 23:41:34 +01:00
|
|
|
} // End llvm namespace
|
|
|
|
|
2001-06-06 22:29:01 +02:00
|
|
|
#endif
|