[LLVMdev] question about Type::canLoslesslyBitCastTo

[Akira Hatanaka]

This is the definition of BITCAST in include/llvm/CodeGen/ISDOpcodes.h:

// BITCAST - This operator converts between integer, vector and FP
// values, as if the value was stored to memory with one type and loaded
// from the same address with the other type (or equivalently for vector
// format conversions, etc).  The source and result are required to have
// the same bit size (e.g.  f32 <-> i32).  This can also be used for
// int-to-int or fp-to-fp conversions, but that is a noop, deleted by
// getNode().

If I can assume the bitcast instruction in LLVM IR has the same definition,
does this mean that the following instruction

%dst = bitcast i32 %src to v2i16

is equivalent to the following sequence of instructions (which I think is
lossless)?

store i32 %src, i32* %ptr
%ptr2 = bitcast i32* %ptr to v2i16*
%dst = load v2i16* %ptr2


I am trying to change all vector types (v2i16 and v4i8) in
include/llvm/IntrinsicsMips.td to i32, but I can't do that because the code
in CodeGenFunction::EmitBuiltinExpr (in clang/CGBuiltin.cpp) raises an
assertion when it calls Type::canLoslesslyBitCastTo to check whether
conversion between v2i16 (or v4i8) and i32 is legal.

To work around this problem, I can put back
CodeGenFunction::EmitMipsBuiltinExpr which was removed in r159368 and add
code to do type conversions, but I prefer not to do this.


On Mon, Jul 2, 2012 at 5:40 PM, Akira Hatanaka <ahatanak at gmail.com> wrote:

> Type::canLoslesslyBitCastTo(Type *Ty) in lib/VMCore/Type.cpp always
> returns false when it checks whether an integer can be bitcast to a vector
> or vice versa.
>
> For example, (i32 => v2i16) or (v2i16 => i32) is false.
>
> But it seems that it returns true if it is checking conversion between two
> vector types which have the same size.
>
> For example, (v4i8 => v2i16) would return true.
>
> What is the rationale behind this?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120709/42698438/attachment.html>