Displaying 7 results from an estimated 7 matches for "ueq".
Did you mean:
req
2008 May 27
1
[LLVMdev] Float compare-for-equality and select optimizationopportunity
Both ZF and PF will be set if unordered, so the code below is IEEE
correct...you want to generate 'fcmp ueq' instead of 'fcmp oqe'
This is the resulting x86 assembly code:
movss xmm0,dword ptr [ecx+4]
ucomiss xmm0,dword ptr [ecx+8]
sete al
setnp dl
test dl,al
mov edx,edi
cmovne edx,ecx
cmovne ecx,esi
cmovne esi,edi...
2008 May 27
0
[LLVMdev] Float compare-for-equality and select optimizationopportunity
...ehalf Of Marc B. Reynolds
Sent: Tuesday, 27 May, 2008 14:07
To: 'LLVM Developers Mailing List'
Subject: Re: [LLVMdev] Float compare-for-equality and select
optimizationopportunity
Both ZF and PF will be set if unordered, so the code below is IEEE
correct...you want to generate 'fcmp ueq' instead of 'fcmp oqe'
This is the resulting x86 assembly code:
movss xmm0,dword ptr [ecx+4]
ucomiss xmm0,dword ptr [ecx+8]
sete al
setnp dl
test dl,al
mov edx,edi
cmovne edx,ecx
cmovne ecx,esi
cmovne esi,edi...
2008 May 27
1
[LLVMdev] Float compare-for-equality andselect optimizationopportunity
...ehalf Of Marc B. Reynolds
Sent: Tuesday, 27 May, 2008 14:07
To: 'LLVM Developers Mailing List'
Subject: Re: [LLVMdev] Float compare-for-equality and select
optimizationopportunity
Both ZF and PF will be set if unordered, so the code below is IEEE
correct...you want to generate 'fcmp ueq' instead of 'fcmp oqe'
This is the resulting x86 assembly code:
movss xmm0,dword ptr [ecx+4]
ucomiss xmm0,dword ptr [ecx+8]
sete al
setnp dl
test dl,al
mov edx,edi
cmovne edx,ecx
cmovne ecx,esi
cmovne esi,edi...
2008 May 27
3
[LLVMdev] Float compare-for-equality and select optimization opportunity
Hi all,
I'm trying to generate code containing an ordered float compare for
equality, and select. The resulting code however has an unordered compare
and some Boolean logic that I think could be eliminated. In C syntax the
code looks like this:
float x, y;
int a, b, c
if(x == y) // Rotate the integers
{
int t;
t = a;
a = b;
2007 Sep 25
0
[LLVMdev] lli vs JIT diffs on FCmp::ne with NaN operands
...s
expected to be 0 then.
If I run the bitcode with lli (JIT off), no problem. If I use the JIT (lli
--force-interpreted=true), then it returns 1.
(Converely, fcmp une with the JIT returns 0 instead of the expected 1 ...
without JIT it returns the expected 0).
The other operators (oeq, oge, ..., ueq, uge, ...) seem to work fine.
Is this a bug with the JIT or have I done to muck this up? I've included
source below which illustrates the problem (with doubles on fcmp one only
... ).
Thanks for your help.
~ David
declare void @exit(i32)
declare void @llvm.memcpy.i32(i8*, i8*, i32, i32)...
2014 Oct 07
4
[LLVMdev] Stange behavior in fp arithmetics on x86 (bug possibly)
...what's goes wrong. But if my
guesses are correct we possibly have a bug in fp arithmetics on x86.
I have the following ir:
@g = constant i64 1
define i32 @main() {
%gval = load i64* @g
%gvalfp = bitcast i64 %gval to double
%fmul = fmul double %gvalfp, -5.000000e-01
%fcmp = fcmp ueq double %fmul, -0.000000e+00
%ret = select i1 %fcmp, i32 1, i32 0
ret i32 %ret
}
And I expected that minimal positive denormalized double times -0.5 is equal
to -0.0, so correct exit code is 1.
llvm-3.4.2 on x86 linux target produced the following assembly:
.file "fpfail.ll"...
2015 Jan 08
2
[LLVMdev] Floating-point range checks
Yes, the modeling of floating-point is trickier. The wrap-around trick used by ConstantRange seems less applicable, and there are the unordered NaNs. Though in all cases, the key abstraction is a lattice of values, so an instance of FPRange should be thought of as a point on a lattice, not an interval. The lattice needs to be complicated enough the cover the cases of interest, but not so