llvm dev - Jul 2015 - [LLVMdev] JIT compilation 2-3 times slower in latest LLVM snapshot

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 :-))

On Sat, Jul 11, 2015 at 5:50 AM, Dibyendu Majumdar
<mobile at majumdar.org.uk> wrote:
> On 11 July 2015 at 13:16, Dibyendu Majumdar <mobile at
majumdar.org.uk> wrote:
>> On 11 July 2015 at 13:14, Caldarale, Charles R
>> <Chuck.Caldarale at unisys.com> wrote:
>>>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
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)?
>>>
>>
>> I haven't changed my build - it is a Release build. Have the
settings
>> in the Released build has changed recently?
>>
>
> 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 11 July 2015 at 18:38, Hayden Livingston <halivingston at gmail.com>
wrote:
> 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.
>
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

On 11 July 2015 at 19:42, Dibyendu Majumdar <mobile at majumdar.org.uk>
wrote:
> 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.
>
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