Issue 60625
Summary c++: converting uint32_t xvalue to rvalue reference to float does not work in this:
Labels new issue
Assignees
Reporter imzhuli
    Please take a look at the following code, which tends to break float into uint parts for transfer, (not for calculation, so endian is not considered) , and to build it back.

The MergeFloat_Wrongly does not generate expected result as MergeFloat does:

inline void SplitFloat32(bool &sign_bit, uint &exponent, uint &mantissa, const float value)
{
    float copy = value;
    uint32_t *p = (uint32_t *)©
    
    sign_bit = (*p & 0x80000000) != 0;
 exponent = (*p & 0x7F800000) >> 23;
    mantissa = (*p & 0x007FFFFF);
}

float MergeFloat(const bool sign_bit, const uint exponent, const uint mantissa)
{ 
// this works:
    uint32_t Temp = uint32_t((sign_bit ? 0x80000000 : 0) | (exponent << 23) | mantissa);
 return (float&)Temp;
}

float MergeFloat_Wrongly(const bool sign_bit, const uint exponent, const uint mantissa)
{
// THIS DOES NOT WORK, the compiler directly convert uint32 xvalue to float, which is expected to be loaded directly
    auto f = (float&&)(uint32_t((sign_bit ? 0x80000000 : 0) | (exponent << 23) | mantissa));
    return f;
}

///////// THE ASM IN MEMORY ////////
    0x100003080 <+0>: pushq  %rbp
    0x100003081 <+1>:  movq   %rsp, %rbp
    0x100003084 <+4>:  movb   %dil, %al
    0x100003087 <+7>:  andb   $0x1, %al
 0x100003089 <+9>:  movb   %al, -0x1(%rbp)
    0x10000308c <+12>: movl %esi, -0x8(%rbp)
    0x10000308f <+15>: movl   %edx, -0xc(%rbp)
 0x100003092 <+18>: movzbl -0x1(%rbp), %eax
    0x100003096 <+22>: shll $0x1f, %eax
    0x100003099 <+25>: movl   -0x8(%rbp), %ecx
 0x10000309c <+28>: shll   $0x17, %ecx
    0x10000309f <+31>: orl    %ecx, %eax
    0x1000030a1 <+33>: movl   -0xc(%rbp), %ecx
    0x1000030a4 <+36>: orl    %ecx, %eax
 ->  0x1000030a6 <+38>: cvtsi2ss %rax, %xmm0
 0x1000030ab <+43>: movss  %xmm0, -0x14(%rbp)

it seems it did a normal direct conversion from uint32(eax)->64(rax)->double(xmm0) with cvtsi2ss

Environment:
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin22.2.0
(btw: g++ seems to have same issue)

I hope it's my understanding of c++ grammar that went wrong. 
Anyway, thanks for any possible reply
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to