Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[windows JIT] incorrect 'frem' behaviour with floats #5425

Closed
baremetaldude mannequin opened this issue Sep 25, 2009 · 9 comments
Closed

[windows JIT] incorrect 'frem' behaviour with floats #5425

baremetaldude mannequin opened this issue Sep 25, 2009 · 9 comments
Labels
bugzilla Issues migrated from bugzilla

Comments

@baremetaldude
Copy link
Mannequin

baremetaldude mannequin commented Sep 25, 2009

Bugzilla Link 5053
Resolution FIXED
Resolved on Nov 13, 2014 18:39
Version trunk
OS Windows NT
CC @asl,@lattner,@lhames

Extended Description

Use following test case:

target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i686-pc-win32"

@​flt = internal global float 12.0e+0
@​str = internal constant [18 x i8] c"Double value:%f \0A\00"

declare i32 @​printf(i8* nocapture, ...) nounwind

define void @​main() {
%flt = load float* @​flt
%float2 = frem float %flt, 5.0
%double1 = fpext float %float2 to double
%yo = call i32(i8* nocapture, ...)* @​printf( i8* getelementptr ([18 x i8]* @​str, i32 0, i64 0), double %double1 )

ret void
}

Running with JIT:
Stack dump:
0. Program arguments: lli test.bc
00000000 (0x41400000 0x40A00000 0x00FEFA40 0x0008D3B1)
00FF003B (0x01A1F6B4 0x01BFB4B0 0x01A1F784 0x5C1E1B36)
0033EA9C (0x01BFB4B0 0x00D81B5C 0x00FE1D20 0x5C1E15EA), llvm::ExecutionEngine::runFunctionAsMain()+0940 bytes(s), e:\external\llvm\lib\executionengine\executionengine.cpp, line 387+0030 byte(s)
00081894 (0x00000002 0x00FE7FD8 0x00FE1D20 0x5C1E155A), main()+2196 bytes(s), e:\external\llvm\tools\lli\lli.cpp, line 218+0064 byte(s)
00A6BFB8 (0x01A1F9D4 0x776F3677 0x7EFDE000 0x01A1FA14), __tmainCRTStartup()+0424 bytes(s), f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 586+0025 byte(s)
00A6BDEF (0x7EFDE000 0x01A1FA14 0x77C99D72 0x7EFDE000), mainCRTStartup()+0015 bytes(s), f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 403
776F3677 (0x7EFDE000 0x7623FA65 0x00000000 0x00000000), BaseThreadInitThunk()+0018 bytes(s)
77C99D72 (0x00A6BDE0 0x7EFDE000 0x00000000 0x00000000), RtlInitializeExceptionChain()+0099 bytes(s)
77C99D45 (0x00A6BDE0 0x7EFDE000 0x00000000 0x00000000), RtlInitializeExceptionChain()+0054 bytes(s)

Running with interpreter:
Double value:2.000000

But if I change floats to doubles - all is OK:

target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i686-pc-win32"

@​flt = internal global double 12.0e+0
@​str = internal constant [18 x i8] c"Double value:%f \0A\00"

declare i32 @​printf(i8* nocapture, ...) nounwind

define void @​main() {
%flt = load double* @​flt
%float2 = frem double %flt, 5.0
%yo = call i32(i8* nocapture, ...)* @​printf( i8* getelementptr ([18 x i8]* @​str, i32 0, i64 0), double %float2 )

ret void
}
@lattner
Copy link
Collaborator

lattner commented Sep 27, 2009

This also works fine for me on macos. This must be a windows specific jit problem.

@baremetaldude
Copy link
Mannequin Author

baremetaldude mannequin commented Sep 27, 2009

I tested it on Windows 7 x64 and Server 2008 x64 ( using 32-bit versions of llvm tools )

@baremetaldude
Copy link
Mannequin Author

baremetaldude mannequin commented Oct 18, 2009

I also experienced same problems with floating point intrinsics - their 'float' versions perform incorrectly. For example:

this will crash runtime:
%flt = load float* ...
... = call float @​llvm.cos.f32(float %flt)

but with doubles all is OK:
%flt = load double* ...
... = call double @​llvm.cos.f64(double %flt)

@asl
Copy link
Collaborator

asl commented Nov 3, 2009

See #5424 for some information

@llvmbot
Copy link
Member

llvmbot commented Sep 17, 2014

Fix for using floating point intrinsics defined as macros
The here problem is that LLI.exe crashes on Windows\X86 when single precession floating point intrinsics like the following are used: acos, asin, atan, atan2, ceil, copysign, cos, cosh, exp, floor, fmin, fmax, fmod, log, pow, sin, sinh, sqrt, tan, tanh

The above intrinsics are defined as inline-expansions in math.h, and are not exported by msvcr120.dll. The DLL does contain the definitions for the intrinsics, but the symbols are not exported (Win32 API GetProcAddress returns null).

For an FREM instruction, the JIT compiler generates a call to a stub for the fmodf() intrinsic, and adds a relocation to fixup at load time. The loader searches the libraries for the function, but fails because the symbol is not exported. So, the call target remains NULL and the execution crashes.

Since the math functions are loaded at JIT/runtime, the JIT can patch CALL instruction directly instead of the searching the libraries’ exported symbols.
However, this fix caused build failures due to unresolved symbols like _fmodf at link time.

Therefore, the current fix defines helper functions in the Runtime link/load library to perform the above operations. The helper functions are exactly the same as the inline definitions in math.h. The address of these helper functions are used to patch up the CALL instruction at load time.

@llvmbot
Copy link
Member

llvmbot commented Oct 2, 2014

Fix for using floating point intrinsics defined as macros
Added a Windows specific test case in Codegen\x86

@lhames
Copy link
Contributor

lhames commented Oct 13, 2014

Hi Swaroop,

The old JIT is deprecated in 3.5, and has been removed entirely on the development branch of LLVM. Could you try this with MCJIT and see if your problem reproduces there?

Just run 'lli -use-mcjit testcase.ll' on 3.5, or simply 'lli testcase.ll' on the development branch where MCJIT is the default.

Cheers,
Lang.

@llvmbot
Copy link
Member

llvmbot commented Oct 25, 2014

Hi Lang,

Is the MCJit supported on Windows?

I tried the following using lli MCJIT (on the development branch of LLVM), but LLI failed with the following error:

Debug\bin\lli.exe llvm\test\ExecutionEngine\hello.ll
LLVM ERROR: Incompatible object format!
Stack dump:
0. Program arguments: Debug\bin\lli.exe D:\enlist\JIT\llvm\test\ExecutionEngine\hello.ll

Thanks,
Swaroop.

@llvmbot
Copy link
Member

llvmbot commented Nov 14, 2014

r221947 - Fix symbol resolution of floating point libc builtins in MCJIT

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@asl @lhames @lattner @llvmbot