search for: pr40074

Hi All, This week I've been focused on removing some of the blockers for people transitioning from ORCv1 to ORCv2. Issue #1 (http://llvm.org/PR40074, http://llvm.org/PR44337): When LLVM codegens floating point constants for COFF we produce named constant pool entries of the form __real@<bitval>. These are stored in COFF COMDAT sections [1] which allow duplicate symbol definitions to be discarded (roughly equivalent to the concept of a we...

...utput is likely* to be: output #1: 5.0 output #2: segfault (*The exact output will depend on the target options used). The problem is that when compiling to COFF (the Windows relocatable object file format) floating point constants may be stored in named COMDAT entries (See e.g. https://llvm.org/PR40074). Only one copy of a constant value is emitted, and other modules will be linked to refer to that copy. In our example, because of lazy compilation, the first copy of the constant 2.0 that the JIT linker will encounter is the one used in anonymous expression #1. The body of foo will link against th...

...ld vs JITLink, and large vs small code model. -- I have added a new LLJIT example program that demonstrates how to use lazy-reexports in ORCv2 to add lazy compilation: llvm/examples/LLJITExamples/LLJITWithLazyReexports. -- COFF support in the JIT still lags ELF and MachO (See e.g. http://llvm.org/PR40074). If there are any COFF experts out there who are interested in helping out with JIT bugs please let me know! Ok -- that’s enough from me for now. If you’re a JIT user, developer, or just casual JIT-development observer (dblaikie), and you have questions, comments, or just feel like introducing yo...