Displaying 4 results from an estimated 4 matches for "fucomi".
Did you mean:
fcomi
2005 Mar 16
0
[LLVMdev] Floating point compare instruction selection
...e normal compare is also
> generated! As far as I can tell it should return right after this:
>
> BuildMI(BB, X86::SAHF, 1);
>
> instead it falls through and goes on to generate the normal compare
> instruction... Am I right?
Nope. It's emitting a compare against zero with fucomi instead of ftst.
fucomi is a PPRO+ instruction that deposits the result of the comparison
into the integer condition codes. This saves having to use SAHF and some
bit-twiddling, so it's usually a bit faster than using ftst. The simple
isel used to produce ftst for compare against zero. If...
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
2005 Mar 17
1
[LLVMdev] Floating point compare instruction selection
...! As far as I can tell it should return right
>> after this:
>>
>> BuildMI(BB, X86::SAHF, 1);
>>
>> instead it falls through and goes on to generate the normal compare
>> instruction... Am I right?
>
> Nope. It's emitting a compare against zero with fucomi instead of ftst.
> fucomi is a PPRO+ instruction that deposits the result of the comparison
> into the integer condition codes. This saves having to use SAHF and some
> bit-twiddling, so it's usually a bit faster than using ftst. The simple
> isel used to produce ftst for compa...
2008 May 12
3
[LLVMdev] LLVM Exception Handling Changes
...poses a lot of flexibility and control to the front-
end. In
> particular, gcc supports the -fhonor-snans flag, which would enable
the trap
> bit on (basically) all floating point operations. The presense of
this flag
> would trigger generation of the fcomi instruction instead of fucomi
(on X86)
> for example, and would inhibit optimizations that would break the
semantics of
> the program.
There is no -fhonor-snans; I guess you mean -fsignaling-nans here.
And -fsignaling-nans doesn't mean use fcomi instead of fucomi; the
-ffinite-math-only option does that.
I th...