Reid,
Most of your uses of getInferredCast fall into one of these categories:
1. They can only be one type of cast.
2. They can be a [bitcast or trunc] or [bitcast or zext] or [bitcast
or sext].
The former should be eliminated obviously, so I want to talk about
the later.
As a specific example, consider:
// gep null, C is equal to C*sizeof(nullty). If nullty is
a known llvm
// type, we can statically fold this.
Constant *R = ConstantInt::get(Type::UIntTy, ElSize);
+ // We know R is unsigned, Idx0 is signed because it must be
an index
+ // through a sequential type (gep pointer operand) which is
always
+ // signed.
+ R = ConstantExpr::getInferredCast(R, false, Idx0->getType(),
true);
+ R = ConstantExpr::getMul(R, Idx0); // signed multiply
+ // R is a signed integer, C is the GEP pointer so -> IntToPtr
+ return ConstantExpr::getCast(Instruction::IntToPtr, R, C-
>getType());
In this case, we know that the cast is either bitcast to uint/int or
a zext to long/ulong [1]. Because you know this, you have a 3 line
comment trying to explain what is going on, and that comment is
confusing (it talks about the types of values, when values are about
to be untyped).
What we really want to do is talk about the possible extension
happening here. As such, I think it would be much cleaner to split
up getInferredCast into:
ConstantExpr::getZExtOrBitCast(..)
ConstantExpr::getSExtOrBitCast(..)
ConstantExpr::getTruncOrBitCast(..)
This would allow writing this code as:
// gep null, C is equal to C*sizeof(nullty). If nullty is
a known llvm
// type, we can statically fold this.
Constant *R = ConstantInt::get(Type::UIntTy, ElSize);
+ R = ConstantExpr::getZExtOrBitCast(R, Idx0->getType());
+ R = ConstantExpr::getMul(R, Idx0); // signed multiply
+ // R is a signed integer, C is the GEP pointer so -> IntToPtr
+ return ConstantExpr::getCast(Instruction::IntToPtr, R, C-
>getType());
The need for the comment goes away. Even *better*, the method can
assert that the types make sense for this (e.g. a trunc isn't from
smaller to larger) as opposed to the totally unconstrained
getInferredCast.
This makes the code a) more self documenting as to what is going on
and b) much more strict about checking itself. What do you think?
Would this allow us to completely eliminate getInferredCast?
-Chris
[1]. As an aside, if you relaxed the type constraints of GEP indices,
this gets much messier.
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
