finalizeObject function implemetation in MCJIT is wrong

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

finalizeObject function implemetation in MCJIT is wrong

Radek Zagorowicz
Hi all.

I found some issue in implementation of finalizeObject function in MCJIT.cpp. If you look at the source code of the function, you can notice that machine code for second "owned" module will never be generated if it doesn't depend on the first one. More over it will cause a crash if entry point isn't in first module. Implementation of finalizeObject using for loop will omit every other module in OwnedModules, because function generateCodeForModule moves module form "added" to "loaded".
Am I right?

Regards.

rodia

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: finalizeObject function implemetation in MCJIT is wrong

David Blaikie
[+Lang, owner of JITs, defender of register allocators, etc]

On Thu, Nov 13, 2014 at 8:29 AM, Radek Zagorowicz <[hidden email]> wrote:
Hi all.

I found some issue in implementation of finalizeObject function in MCJIT.cpp. If you look at the source code of the function, you can notice that machine code for second "owned" module will never be generated if it doesn't depend on the first one. More over it will cause a crash if entry point isn't in first module. Implementation of finalizeObject using for loop will omit every other module in OwnedModules, because function generateCodeForModule moves module form "added" to "loaded".
Am I right?

Regards.

rodia

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: finalizeObject function implemetation in MCJIT is wrong

Lang Hames
Hi Radek,

Sorry for the delayed response. I haven't had time to check your analysis yet, but you're probably right: MCJIT's support for multiple modules in a single instance is patchy at best.

Do you have a test case (e.g. an lli invocation) that triggers this bug, or is this something you discovered just by reading the code?

Cheers,
Lang. 

On Thu, Nov 13, 2014 at 8:46 AM, David Blaikie <[hidden email]> wrote:
[+Lang, owner of JITs, defender of register allocators, etc]

On Thu, Nov 13, 2014 at 8:29 AM, Radek Zagorowicz <[hidden email]> wrote:
Hi all.

I found some issue in implementation of finalizeObject function in MCJIT.cpp. If you look at the source code of the function, you can notice that machine code for second "owned" module will never be generated if it doesn't depend on the first one. More over it will cause a crash if entry point isn't in first module. Implementation of finalizeObject using for loop will omit every other module in OwnedModules, because function generateCodeForModule moves module form "added" to "loaded".
Am I right?

Regards.

rodia

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: finalizeObject function implemetation in MCJIT is wrong

Radek Zagorowicz
I will prepare this test case with lli ASAP.

2014-11-18 19:48 GMT+01:00 Lang Hames <[hidden email]>:
Hi Radek,

Sorry for the delayed response. I haven't had time to check your analysis yet, but you're probably right: MCJIT's support for multiple modules in a single instance is patchy at best.

Do you have a test case (e.g. an lli invocation) that triggers this bug, or is this something you discovered just by reading the code?

Cheers,
Lang. 

On Thu, Nov 13, 2014 at 8:46 AM, David Blaikie <[hidden email]> wrote:
[+Lang, owner of JITs, defender of register allocators, etc]

On Thu, Nov 13, 2014 at 8:29 AM, Radek Zagorowicz <[hidden email]> wrote:
Hi all.

I found some issue in implementation of finalizeObject function in MCJIT.cpp. If you look at the source code of the function, you can notice that machine code for second "owned" module will never be generated if it doesn't depend on the first one. More over it will cause a crash if entry point isn't in first module. Implementation of finalizeObject using for loop will omit every other module in OwnedModules, because function generateCodeForModule moves module form "added" to "loaded".
Am I right?

Regards.

rodia

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: finalizeObject function implemetation in MCJIT is wrong

Radek Zagorowicz
Hi Lang.

I prepared the test case.
Download file from attachment.
Compile main.cpp and run it. test1.ll and test2.ll should be in the working folder.
When you uncomment line 49 in main.cpp it starts working fine.

My configuration is:
llvm 3.5
msvc 11 (VS 2012)
architecture x86

Regards.

P.S. After preparing this test case I noticed that this bug is fixed in the newest implementation of MCJIT in llvm trunk branch. :)


2014-11-19 11:12 GMT+01:00 Radek Zagorowicz <[hidden email]>:
I will prepare this test case with lli ASAP.

2014-11-18 19:48 GMT+01:00 Lang Hames <[hidden email]>:
Hi Radek,

Sorry for the delayed response. I haven't had time to check your analysis yet, but you're probably right: MCJIT's support for multiple modules in a single instance is patchy at best.

Do you have a test case (e.g. an lli invocation) that triggers this bug, or is this something you discovered just by reading the code?

Cheers,
Lang. 

On Thu, Nov 13, 2014 at 8:46 AM, David Blaikie <[hidden email]> wrote:
[+Lang, owner of JITs, defender of register allocators, etc]

On Thu, Nov 13, 2014 at 8:29 AM, Radek Zagorowicz <[hidden email]> wrote:
Hi all.

I found some issue in implementation of finalizeObject function in MCJIT.cpp. If you look at the source code of the function, you can notice that machine code for second "owned" module will never be generated if it doesn't depend on the first one. More over it will cause a crash if entry point isn't in first module. Implementation of finalizeObject using for loop will omit every other module in OwnedModules, because function generateCodeForModule moves module form "added" to "loaded".
Am I right?

Regards.

rodia

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev






_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

test2.ll (102 bytes) Download Attachment
test1.ll (110 bytes) Download Attachment
main.cpp (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: finalizeObject function implemetation in MCJIT is wrong

Lang Hames
Ahh. Glad to hear that things have improved on trunk. :)

- Lang.

On Thu, Nov 20, 2014 at 6:20 AM, Radek Zagorowicz <[hidden email]> wrote:
Hi Lang.

I prepared the test case.
Download file from attachment.
Compile main.cpp and run it. test1.ll and test2.ll should be in the working folder.
When you uncomment line 49 in main.cpp it starts working fine.

My configuration is:
llvm 3.5
msvc 11 (VS 2012)
architecture x86

Regards.

P.S. After preparing this test case I noticed that this bug is fixed in the newest implementation of MCJIT in llvm trunk branch. :)


2014-11-19 11:12 GMT+01:00 Radek Zagorowicz <[hidden email]>:
I will prepare this test case with lli ASAP.

2014-11-18 19:48 GMT+01:00 Lang Hames <[hidden email]>:
Hi Radek,

Sorry for the delayed response. I haven't had time to check your analysis yet, but you're probably right: MCJIT's support for multiple modules in a single instance is patchy at best.

Do you have a test case (e.g. an lli invocation) that triggers this bug, or is this something you discovered just by reading the code?

Cheers,
Lang. 

On Thu, Nov 13, 2014 at 8:46 AM, David Blaikie <[hidden email]> wrote:
[+Lang, owner of JITs, defender of register allocators, etc]

On Thu, Nov 13, 2014 at 8:29 AM, Radek Zagorowicz <[hidden email]> wrote:
Hi all.

I found some issue in implementation of finalizeObject function in MCJIT.cpp. If you look at the source code of the function, you can notice that machine code for second "owned" module will never be generated if it doesn't depend on the first one. More over it will cause a crash if entry point isn't in first module. Implementation of finalizeObject using for loop will omit every other module in OwnedModules, because function generateCodeForModule moves module form "added" to "loaded".
Am I right?

Regards.

rodia

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev







_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev