[LLVMdev] Definition of the bitcast instruction for vectors

[Daniel Sanders]

From: Eli Friedman [mailto:eli.friedman at gmail.com]
Sent: 16 August 2013 18:37
To: Daniel Sanders
Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
Subject: Re: [LLVMdev] Definition of the bitcast instruction for vectors

On Fri, Aug 16, 2013 at 7:51 AM, Daniel Sanders <Daniel.Sanders at imgtec.com<mailto:Daniel.Sanders at imgtec.com>> wrote:
Hi,

>From http://llvm.org/docs/LangRef.html#bitcast-to-instruction:

The 'bitcast' instruction converts value to type ty2. It is always a no-op cast because no bits change with this conversion. The conversion is done as if the value had been stored to memory and read back as type ty2. Pointer (or vector of pointers) types may only be converted to other pointer (or vector of pointers) types with this instruction if the pointer sizes are equal. To convert pointers to other types, use the inttoptr or ptrtoint instructions first.

If I understand the definition correctly, then:
%1 = bitcast <8 x i16> %0 to <4 x i32>
Should be equivalent to:
                store <8 x i16> %0, <8 x i16>* %ptr
%1 = load <4 x i32>* %ptr
Which the definition above asserts is a no-op cast. However, the store/load sequence is not a no-op cast for vector types when the target does not treat the whole vector as either little or big-endian. MIPS MSA stores vector elements in big or little endian order according to a configuration bit, but irrespective of this bit the lanes are stored in ascending order.  For example, <4 x i32> <i32 1, i32 2, i32 3, i32 4> would be stored as this in big-endian mode:
%ptr   : 00 00 00 01
%ptr+4 : 00 00 00 02
%ptr+8 : 00 00 00 03
%ptr+12: 00 00 00 04
And this in little-endian mode:
%ptr   : 01 00 00 00
%ptr+4 : 02 00 00 00
%ptr+8 : 03 00 00 00
%ptr+12: 04 00 00 00

How should I resolve this conflicting definition?



It's a "no-op" cast in the sense that there isn't any math involved; it's not a statement about the number of necessary machine instructions.

-Eli

Thanks for the clarification.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130819/a3a46a4c/attachment.html>