search for: 171604c7

Displaying 5 results from an estimated 5 matches for "171604c7".

Did you mean: 17160487
2005 Mar 11
0
[LLVMdev] FP Intrinsics
...v ecx,76E4560h 1716047C mov dword ptr [esp],ecx 1716047F call eax 17160481 fsub dword ptr ds:[16237240h] 17160487 fabs 17160489 fst qword ptr [esp+14h] 1716048D ftst 1716048F fstp st(0) 17160491 fnstsw ax 17160493 sahf 17160494 jbe 171604C7 1716049A mov eax,19D8B76h 1716049F mov ecx,16237200h 171604A4 mov dword ptr [esp],ecx 171604A7 mov ecx,15900060h 171604AC mov dword ptr [esp+4],ecx 171604B0 fld qword ptr [esp+14h] 171604B4 fstp dword ptr [esp+8] 171604B8 mov ec...
2005 Mar 11
5
[LLVMdev] FP Intrinsics
Hello, I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added work with the X86ISelPattern, but I'm having some difficulties understanding what needs to be done. I assume I have to add new nodetypes for the FP instructions to SelectionDAGNodes.h, and make nodes for these in SelectionDAGLowering::visitCall when I find the intrinsic... The part I don't quite
2005 Mar 17
1
[LLVMdev] Floating point compare instruction selection
...st(0) 17160467 jbe 17160498 the ISelSimple generates: 1716047F call eax 17160481 fsub dword ptr ds:[16237240h] 17160487 fabs 17160489 fst qword ptr [esp+14h] 1716048D ftst 1716048F fstp st(0) 17160491 fnstsw ax 17160493 sahf 17160494 jbe 171604C7 m.
2005 Mar 16
0
[LLVMdev] Floating point compare instruction selection
On Wed, 16 Mar 2005, Morten Ofstad wrote: > Hello, > > I didn't get any reply to my previous mail about adding floating point > intrinsics to the X86 pattern instruction selector... And I could really need > some help. Sorry about that, it slipped through the cracks. :( > Anyway, I think my confusion was caused partly by an already > existing bug in the instruction
2005 Mar 16
2
[LLVMdev] Floating point compare instruction selection
Hello, I didn't get any reply to my previous mail about adding floating point intrinsics to the X86 pattern instruction selector... And I could really need some help. Anyway, I think my confusion was caused partly by an already existing bug in the instruction selection for floating point compares. The case which emits code for the special case of comparing against constant 0.0 does not