JIT compilation 2-3 times slower in latest LLVM snapshot

Hi

I updated my clone of the LLVM github mirror today and I am finding
that the JIT compilation is now 2-3 times slower. The last time I
refreshed was maybe 2 weeks ago. Is there a known change that would
explain this?

This is on Windows 8.1 64-bit. I am using MCJIT.

Thanks and Regards
Dibyendu

To give you some idea:

On Linux VM running on the same machine, using LLVM 3.6.1, the time
taken for my test:

../build/lua -e"_U=true;ravi.optlevel(2); ravi.auto(true,1)" all.lua
total time: 70.80s (wall time: 73s)

On Windows natively running against latest LLVM snapshot:

..\build\Release\lua.exe -e"_U=true; ravi.optlevel(2);
ravi.auto(true,1)" all.lua
total time: 333.65s (wall time: 333s)

My benchmarks run fine hence my view that it is taking longer to JIT
rather than an issue with the generated code.

Unfortunately I don't have the timing I was getting previously but
from memory it was roughly similar to the Linux timing above.

Thanks and Regards
Dibyendu

From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
On Behalf Of Dibyendu Majumdar
Subject: [LLVMdev] JIT compilation 2-3 times slower in latest LLVM snapshot

I updated my clone of the LLVM github mirror today and I am finding
that the JIT compilation is now 2-3 times slower. The last time I
refreshed was maybe 2 weeks ago. Is there a known change that would
explain this?

Debug+Asserts build rather than Release (or Release+Asserts)?

- Chuck

I haven't changed my build - it is a Release build. Have the settings
in the Released build has changed recently?

Regards

Just to be sure I completely rebuilt LLVM (below are some snippets
from the build):

C:\github\llvm\build>cmake -DCMAKE_INSTALL_PREFIX=c:\LLVM37
-DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD="X86" -G "Visual
Studio 14 Win64" ..
-- Target triple: x86_64-pc-win32
-- Native target architecture is X86
-- Threads enabled.
-- Doxygen disabled.
-- Sphinx disabled.
-- Go bindings disabled.
-- Could NOT find OCaml (missing: OCAMLFIND OCAML_VERSION OCAML_STDLIB_PATH)
-- OCaml bindings disabled.
-- Using Debug VC++ CRT: MDd
-- Using Release VC++ CRT: MD
-- Using MinSizeRel VC++ CRT: MD
-- Using RelWithDebInfo VC++ CRT: MD
-- Using Release VC++ CRT: MD
-- Constructing LLVMBuild project information
-- LLVMHello ignored -- Loadable modules not supported on this platform.
-- Targeting X86
-- BugpointPasses ignored -- Loadable modules not supported on this platform.
-- Configuring done
-- Generating done
-- Build files have been written to: C:/github/llvm/build

Visual Studio output:

140>Project not selected to build for this solution configuration
141>------ Skipped Build: Project: check-all, Configuration: Release x64 ------
141>Project not selected to build for this solution configuration
142>------ Skipped Build: Project: check, Configuration: Release x64 ------
142>Project not selected to build for this solution configuration
========== Build: 136 succeeded, 0 failed, 0 up-to-date, 6 skipped ==========

and

1>------ Build started: Project: LTO_exports, Configuration: Release x64 ------
2>------ Build started: Project: intrinsics_gen, Configuration:
Release x64 ------
3>------ Build started: Project: LibOptionsTableGen, Configuration:
Release x64 ------
4>------ Build started: Project: X86CommonTableGen, Configuration:
Release x64 ------
5>------ Build started: Project: llvm-ranlib, Configuration: Release x64 ------
6>------ Build started: Project: llvm-lib, Configuration: Release x64 ------
7>------ Build started: Project: INSTALL, Configuration: Release x64 ------
7> -- Install configuration: "Release"

Same issue.

If you could create a single executable with a repro, and publish them
somewhere (both the old llvm and new one which is slower), we could
look at it. It's hard to say otherwise unless someone truly knows of a
change.

I'm interested in looking at this, because my experience has been
opposite, compile times improved for my compiler in the past month. So
I'm inclined to understand what your codegen path is doing to see if
there's some pathological case you may be hitting (which I'd like to
avoid for my case :-))

Hi Hayden,

As I am not sure exactly when I refreshed my LLVM clone (it was
recently however) - I would have to go back in time and determine when
the issue was introduced. This will take some work and time to do.

Just looking at the release I prepared a week ago and comparing the
results from today I see:

Release 0.6 (1 week ago; using LLVM snapshot earlier than that):
total time: 123.71s (wall time: 124s)
https://github.com/dibyendumajumdar/ravi/releases/tag/0.6

Release 0.7 (snapshot taken today)
total time: 333.65s (wall time: 333s)
https://github.com/dibyendumajumdar/ravi/releases/tag/0.7

Both are slower than the 3.6.1 release I am using in my Linux builds.

Regards
Dibyendu

After rebooting the performance has gone back to normal. As I ran
above two tests at the same time there was nothing wrong with the
system at the time (because then v0.6 would have behaved badly as
well), so I don't know what to think of this.

v0.7
total time: 121.57s (wall time: 121s)

Regards

Dibyendu