search for: fptoui

I am a little confused by the results of the result of fptoui ... seems to conflict with the instructions semantics as defined in the language reference (http://llvm.org/docs/LangRef.html#i_fptoui): %tmp1001 = fptoui float 1.0E+300 to i1 ; % yields tmp1001 = 0 on my machine! but the ref says: %Y = fptoui float 1.0E+300 to i1 ; yields i1:true (...

Hi Joe & Michael, In rev. 151382 you have changed the fptoui implementation of the x86 codegen for win32. Before the change fptoui was lowered to flds 16(%esp) fisttpll 8(%esp) movl 8(%esp), %eax After the change fptoui is lowered to flds 40(%esp) calll _ftol2 Please note that the assumption that _ftol2 doesn't modify ECX isn...

Hi everyone! The fptoui/fptosi instructions are currently specified to return a poison value if the rounded-towards-zero floating point number cannot be represented by the target integer type. The motivation for this behavior is that overflowing float to int casts in C are undefined behavior. However, many newer language...

...independent intrinsic or IR, since this behavior is not actually particular to WebAssembly. On Mon, Nov 5, 2018 at 2:37 PM Finkel, Hal J. via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 11/05/2018 07:26 AM, Nikita Popov via llvm-dev wrote: > > Hi everyone! > > The fptoui/fptosi instructions are currently specified to return a poison > value if the rounded-towards-zero floating point number cannot be > represented by the target integer type. The motivation for this behavior is > that overflowing float to int casts in C are undefined behavior. > > Howe...

...u need to implement? What exactly is the calling convention? Which registers are clobbered etc. There is only one (that I know about so far). The MSVCRT `_ftol2` function implements floating-point-to-unsigned conversion for i386 targets, and LLVM 3.0 calls it with the cdecl calling convention for `fptoui to i64` when targeting i386-pc-win32. However, it has its own calling convention: The input value is taken from ST0 and popped off of the x87 stack, and the return value is given in EDX:EAX. EAX, EDX, and ST0 are clobbered (the latter by popping the stack). The function creates a stack frame. It me...

Hi, I've found a test case where SelectionDAG is doing an undefined behavior optimization, and I need help determining whether or not this is legal. Here is the example IR: define void @test(<4 x i8> addrspace(1)* %out, float %a) { %uint8 = fptoui float %a to i8 %vec = insertelement <4 x i8> <i8 0, i8 0, i8 0, i8 0>, i8 %uint8, i32 0 store <4 x i8> %vec, <4 x i8> addrspace(1)* %out ret void } Since %vec is a 32-bit vector, a common way to implement this function on a target with 32-bit registers would be to zer...

...is is fully correct, but it seems to work in simple test cases. Am I on the right track? Could this patch ever break in cases where the operand's vreg doesn't happen to get mapped to ST0? I'm still a bit foggy on the internals of X86FloatingPoint. One thing I noticed is that fptosi and fptoui both seem to always emit a redundant SSE load/store when SSE is enabled, because of the check at Target/X86/X86ISelLowering.cpp:7948. Can this check be easily modified so it doesn't store if the operand is already in memory and not actually in an SSE register? Should FP_TO_INTHelper switch over...

On Jan 18, 2012, at 8:56 PM, Joe Groff wrote: > 2012/1/18 Jakob Stoklund Olesen <stoklund at 2pi.dk>: >> This should work: >> %1 = call i64 asm "call __ftol2", "=A,{st},~{dirflag},~{fpsr},~{flags},~{st}" (double %x) nounwind > > Forgive me for being slow, but what would be the best way to implement > the equivalent of that inline asm as a custom

On Jan 20, 2012, at 1:58 PM, Joe Groff wrote: > The integer runtime functions (_allmul, _alldiv, etc. for 64-bit > integer arithmetic) all appear to be straight-up stdcall. _ftol2 is > the only weird one. (There is an _ftol routine with the same calling > convention as _ftol2, but AFAIK it's only for backward compatibility > with older MSVC runtimes.) I'm far from an MSVC

Changing the list from cfe-dev to llvm-dev > On 20 Apr 2017, at 4:52 AM, Michael Clark <michaeljclark at mac.com> wrote: > > I’m getting close. I think it may be an issue with an individual intrinsic. I’m looking for the X86 lowering of Instruction::FPToUI. > > I found a comment around the rationale for using a conditional move versus a branch. I believe the predicate logic using a conditional move is causing INEXACT to be set from the other side of the predicate as the lowered x86_64 code executes both conversions whereas GCC uses a branch. T...

.... > I'm still a bit > foggy on the internals of X86FloatingPoint. Look at the code handling INLINE_ASM. You need to do the same, except you have fixed arguments STUses=1 and STClobbers=1, ST*=0. That should greatly simplify the code you need. > One thing I noticed is that fptosi and fptoui both seem to always emit > a redundant SSE load/store when SSE is enabled, because of the check > at Target/X86/X86ISelLowering.cpp:7948. Can this check be easily > modified so it doesn't store if the operand is already in memory and > not actually in an SSE register? Should FP_TO_I...

...exactly is the calling convention? Which registers are clobbered etc. > > There is only one (that I know about so far). The MSVCRT `_ftol2` > function implements floating-point-to-unsigned conversion for i386 > targets, and LLVM 3.0 calls it with the cdecl calling convention for > `fptoui to i64` when targeting i386-pc-win32. However, it has its own > calling convention: The input value is taken from ST0 and popped off > of the x87 stack, and the return value is given in EDX:EAX. EAX, EDX, > and ST0 are clobbered (the latter by popping the stack). The function > creates...

On Jan 18, 2012, at 3:50 PM, Joe Groff wrote: > Hi everyone. On i386--win32 targets, LLVM tries to use the MSVCRT > routine _ftol2 for floating-point to unsigned conversions, but this > function has a nonstandard calling convention LLVM doesn't understand. > It takes its input operand on the x87 stack as ST0, which it pops off > of the stack before returning. The return value

2012/1/18 Jakob Stoklund Olesen <stoklund at 2pi.dk>: > This should work: > %1 = call i64 asm "call __ftol2", "=A,{st},~{dirflag},~{fpsr},~{flags},~{st}" (double %x) nounwind Thanks Jakob, the ~{st} constraint does the trick. It wasn't clear to me that "clobbers" means "pops" for x87 registers. -Joe

2012/1/18 Jakob Stoklund Olesen <stoklund at 2pi.dk>: > This should work: > %1 = call i64 asm "call __ftol2", "=A,{st},~{dirflag},~{fpsr},~{flags},~{st}" (double %x) nounwind Forgive me for being slow, but what would be the best way to implement the equivalent of that inline asm as a custom lowering for an instruction? Can I just create a CallInst and tell it to

On Thu, Jan 19, 2012 at 10:39 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Alright.  We definitely don't want to model it as a general call, then.  Normal calls clobber lots of registers. > > The options are: > > 1. Use a pseudo-instruction that X86FloatingPoint understands and turns into a call after arranging for the argument to be in ST0. >   You should

On Tue, Jan 24, 2012 at 4:32 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Yes, your definition of the new instruction looks sane. > > However, you shouldn't expand the instruction right away in EmitInstrWithCustomInserter(), and leaving the pseudo and call instructions side by side is not going to work. > > Just leave the pseudo-instruction alone until it hits

On Jul 19, 2013, at 12:30 PM, Craig Topper <craig.topper at gmail.com> wrote: > Here's my attempt at a fix. Adding Jakob to make sure I did this right. Patch LGTM. Thanks, /jakob

...gt; lib/Target/X86/X86InstrCompiler.td like I've done below. I don't have > a Windows machine to test myself. > > let Defs = [EAX, EDX, ECX, EFLAGS], FPForm = SpecialFP in { > def WIN_FTOL_32 : I<0, Pseudo, (outs), (ins RFP32:$src), > "# win32 fptoui", > [(X86WinFTOL RFP32:$src)]>, > Requires<[In32BitMode]>; > > def WIN_FTOL_64 : I<0, Pseudo, (outs), (ins RFP64:$src), > "# win32 fptoui", > [(X86WinFTOL RFP64:$src)...

...to the Defs of this part of lib/Target/X86/X86InstrCompiler.td like I've done below. I don't have a Windows machine to test myself. let Defs = [EAX, EDX, ECX, EFLAGS], FPForm = SpecialFP in { def WIN_FTOL_32 : I<0, Pseudo, (outs), (ins RFP32:$src), "# win32 fptoui", [(X86WinFTOL RFP32:$src)]>, Requires<[In32BitMode]>; def WIN_FTOL_64 : I<0, Pseudo, (outs), (ins RFP64:$src), "# win32 fptoui", [(X86WinFTOL RFP64:$src)]>, Re...