llvm-6502/test/CodeGen/X86/2008-10-06-x87ld-nan-2.ll
Dale Johannesen 2df5eec2ff Be more precise about which conversions of NaNs
are Inexact.  (These are not Inexact as defined
by IEEE754, but that seems like a reasonable way
to abstract what happens:  information is lost.)



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57218 91177308-0d34-0410-b5e6-96231b3b80d8
2008-10-06 22:59:10 +00:00

19 lines
801 B
LLVM

; ModuleID = 'nan.bc'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-f80:32:32-v64:64:64-v128:128:128-a0:0:64"
target triple = "i686-apple-darwin8"
; RUN: llvm-as < %s | llc -march=x86 -mattr=-sse2,-sse3,-sse | grep fldt | count 3
; it is not safe to shorten any of these NaNs.
declare x86_stdcallcc void @_D3nan5printFeZv(x86_fp80 %f)
@_D3nan4rvale = global x86_fp80 0xK7FFF8001234000000000 ; <x86_fp80*> [#uses=1]
define i32 @main() {
entry_nan.main:
%tmp = load x86_fp80* @_D3nan4rvale ; <x86_fp80> [#uses=1]
call x86_stdcallcc void @_D3nan5printFeZv(x86_fp80 %tmp)
call x86_stdcallcc void @_D3nan5printFeZv(x86_fp80 0xK7FFF8001234000000000)
call x86_stdcallcc void @_D3nan5printFeZv(x86_fp80 0xK7FFFC001234000000400)
ret i32 0
}