llvm dev - Aug 2013 - [LLVMdev] Definition of the bitcast instruction for vectors

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?

Daniel Sanders
Leading Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited
t: +44 (0)1923 260511
www.imgtec.com<http://www.imgtec.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130816/b60a4d83/attachment.html>

On Fri, Aug 16, 2013 at 7:51 AM, Daniel Sanders
<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130816/b0af40be/attachment.html>

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>