# Ocamlopt vs Duplo/LLVM code generation **URL:** \ **Category:** Ecosystem\ **Tags:** code-generation, compilation, compiler\ **Created:** [August 26, 2020, 9:29pm UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303 "2020-08-26T21:29:34Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![nand](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/nand/32/2337_2.png) [@nand](https://discuss.ocaml.org/u/nand)\ **Post date:** [August 26, 2020, 9:29pm UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/1 "2020-08-26T21:29:34Z")
We have recently presented the Duplo Post-Link optimiser, which among other things manages to compile OCaml to machine code through the code generator of LLVM on amd64. I built a histogram comparing code generated by ocamlopt and the LLVM backend, without enabling any optimisations at the LLIR level, on the intermediate representation used by the Duplo framework. > The histogram counts the occurrence of each instruction in ocamlopt. I have also included some comments to highlight which instruction choices are likely to be better/more compact - while one of the issue has been since addressed, there data does highlight a few other opportunities for improvement. ---
**Author:** ![bluddy](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/bluddy/32/104_2.png) [@bluddy](https://discuss.ocaml.org/u/bluddy)\ **Post date:** [August 26, 2020, 9:59pm UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/2 "2020-08-26T21:59:16Z")
Could you explain the LLVM path in a little more detail? How are you compiling via LLVM? ---
**Author:** ![mseri](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/mseri/32/91_2.png) [@mseri](https://discuss.ocaml.org/u/mseri)\ **Post date:** [August 26, 2020, 10:00pm UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/3 "2020-08-26T22:00:40Z")
There is a nice ICFP paper on this: [https://dl.acm.org/doi/10.1145/3408980](https://dl.acm.org/doi/10.1145/3408980) ---
**Author:** ![nand](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/nand/32/2337_2.png) [@nand](https://discuss.ocaml.org/u/nand)\ **Post date:** [August 26, 2020, 10:04pm UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/4 "2020-08-26T22:04:32Z")
We do not compile to LLVM IR, but to a representation we call LLIR that keeps track of the types of virtual registers in OCaml - int, float, value or address. The IR is then lowered to LLVM’s MachineIR through the SelectionDAG instruction selector. A custom instruction was added to handle GC metadata and some passes were modified to preserve the semantics of GC roots. ---
**Author:** ![lambda\_foo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/lambda_foo/32/275_2.png) [@lambda\_foo](https://discuss.ocaml.org/u/lambda_foo)\ **Post date:** [August 27, 2020, 2:56am UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/5 "2020-08-27T02:56:51Z")
I missed the NY QA time for this paper. Was there an answer to whether this will work with MultiCore OCaml work? And how can someone try this out, is there an opam switch for it? ---
**Author:** ![bluddy](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/bluddy/32/104_2.png) [@bluddy](https://discuss.ocaml.org/u/bluddy)\ **Post date:** [August 27, 2020, 3:03am UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/6 "2020-08-27T03:03:12Z")
They mention it in the paper. There’s nothing preventing multicore from working, but the code hasn’t been adapted to it. ---
**Author:** ![lambda\_foo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/lambda_foo/32/275_2.png) [@lambda\_foo](https://discuss.ocaml.org/u/lambda_foo)\ **Post date:** [August 27, 2020, 3:04am UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/7 "2020-08-27T03:04:27Z")
Thanks, I’ve not fully read the paper. ---
**Author:** ![nand](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/nand/32/2337_2.png) [@nand](https://discuss.ocaml.org/u/nand)\ **Post date:** [August 27, 2020, 6:45am UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/8 "2020-08-27T06:45:37Z")
There are instructions on setting up a pin [here](https://github.com/nandor/llir-opt). Unfortunately, some packages which rely on amd64 inline assembly or do not query the ocaml environment for the right C compiler to use (CC=`llir-gcc`) will not install at the moment. We have the required diffs/versions at in [our version](https://github.com/nandor/llir-benchmark/tree/master/dependencies) of the sandmark benchmark suite and we will create a repository out of them. ---
**Author:** ![xavierleroy](https://avatars.discourse-cdn.com/v4/letter/x/a9adbd/32.png) [@xavierleroy](https://discuss.ocaml.org/u/xavierleroy)\ **Post date:** [August 27, 2020, 9:51am UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/9 "2020-08-27T09:51:00Z")
Thanks for all the data and the suggestions. As you mention, a couple of them (32-bit immediate load into 64-bit register; no “call” instruction to set up trap handlers) are already implemented in OCaml 4.11. The ocamlopt back-end was initially designed for RISC processors, with load instructions separate from computational instructions, so things like “callq (reg64)” just don’t fit. ---
**Author:** ![anmolsahoo25](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@anmolsahoo25](https://discuss.ocaml.org/u/anmolsahoo25)\ **Post date:** [September 15, 2020, 12:27pm UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/10 "2020-09-15T12:27:37Z")
@nandor, I have a package which uses AVX intrinsics. While compiling, the error I get is - > Do not know how to split the result of this operator With the invocation being - ```auto clang-12 -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -disable-llvm-verifier -discard-value-names -main-file-name bigstringaf_simd_avx2.c -mrelocation-model pic -pic-level 2 -mframe-pointer=none -relaxed-aliasing -fmath-errno -fno-rounding-math -no-integrated-as -mconstructor-aliases -target-cpu x86-64 -target-feature +avx2 -tune-cpu generic -fno-split-dwarf-inlining -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -v -resource-dir /home/anmol/.opam/llir/llvm/lib/clang/12.0.0 -D _FILE_OFFSET_BITS=64 -D _REENTRANT -I /home/anmol/.opam/llir/lib/ocaml -mllvm -llir -llir -isysroot /home/anmol/.opam/llir -internal-externc-isystem /home/anmol/.opam/llir/include -internal-isystem /home/anmol/.opam/llir/llvm/lib/clang/12.0.0/include -O2 -Wall -Wextra -Wpedantic -fno-dwarf-directory-asm -fdebug-compilation-dir /home/anmol/bigstringaf/_build/default/lib -ferror-limit 19 -fwrapv -fgnuc-version=4.2.1 -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/bigstringaf_simd_avx2-ff6282.s -x c bigstringaf_simd_avx2.c ``` I am assuming this is because lowering for these intrinsics has not been implemented maybe? Any thoughts on this? ---
**Author:** ![nand](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/nand/32/2337_2.png) [@nand](https://discuss.ocaml.org/u/nand)\ **Post date:** [September 15, 2020, 12:54pm UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/11 "2020-09-15T12:54:10Z")
Unfortunately the C-to-LLIR lowering in Clang does not yet support SSE intrinsics. ---
**Author:** ![anmolsahoo25](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@anmolsahoo25](https://discuss.ocaml.org/u/anmolsahoo25)\ **Post date:** [September 16, 2020, 6:21pm UTC](https://discuss.ocaml.org/t/ocamlopt-vs-duplo-llvm-code-generation/6303/12 "2020-09-16T18:21:21Z")
Oh okay. Makes sense. Thank you! Really enjoyed reading the paper and its definitely pretty cool work.