# Progress with Julia codegen and LLVM 4.0

**URL:** https://discourse.julialang.org/t/progress-with-julia-codegen-and-llvm-4-0/2650
**Category:** Internals & Design
**Tags:** question, announcement
**Created:** [March 14, 2017, 2:40am UTC](https://discourse.julialang.org/t/progress-with-julia-codegen-and-llvm-4-0/2650 "2017-03-14T02:40:41Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![sc0ttwad3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sc0ttwad3/32/3908_2.png) [@sc0ttwad3](https://discourse.julialang.org/u/sc0ttwad3)
#### Post date: [March 14, 2017, 2:40am UTC](https://discourse.julialang.org/t/progress-with-julia-codegen-and-llvm-4-0/2650/1 "2017-03-14T02:40:42Z")

</div>

Just wondering about the status of Julia 0.6 and codegen to the LLVM 4,0 release today.

A lot of optimizations and more, like one small item out of hundreds, where LLVM 4.0 incorporates features like: “ **\_\_vectorcall** uses more registers for arguments than **\_\_fastcall** or the default x64 calling convention use. Use **\_\_vectorcall** to _speed functions that pass several floating-point or SIMD vector arguments_ and perform operations that take advantage of the arguments loaded in registers.”

I’m wondering if prior major LLVM releases made significant gains in performance?

* * *

[llvm-announce] LLVM 4.0.0 Release  
Hans Wennborg via llvm-announce llvm-announce at [lists.llvm.org](http://lists.llvm.org)  
Mon Mar 13 09:55:29 PDT 2017

It is my pleasure to announce that LLVM 4 is now available.

Get it here: [LLVM Download Page](http://llvm.org/releases/download.html#4.0.0)

LLVM is now using a new versioning scheme, increasing the major  
version number with each major release. Stable updates to this release  
will be versioned 4.0.x, and the next major release, six months from  
now, will be version 5.0.0. For more information, see

> **[LLVM's New Versioning Scheme](http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html)**
>
> Historically, LLVM's major releases always added "0.1" to the version number, producing major versions like 3.8, 3.9, and 4.0 (expected by March 2017). With our next release though, we're changing this.

This release is the result of the community’s work over the past six  
months, including: use of profile data in ThinLTO, more aggressive  
aggressive dead code elimination, experimental support for coroutines,  
experimental AVR target, better GNU ld compatibility and significant  
performance improvements in LLD, as well as improved optimizations,  
many bug fixes and more.

See the release notes for more details:  
[http://llvm.org/releases/4.0.0/docs/ReleaseNotes.html](http://llvm.org/releases/4.0.0/docs/ReleaseNotes.html)  
[http://llvm.org/releases/4.0.0/tools/clang/docs/ReleaseNotes.html](http://llvm.org/releases/4.0.0/tools/clang/docs/ReleaseNotes.html)  
[http://llvm.org/releases/4.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html](http://llvm.org/releases/4.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html)  
[http://llvm.org/releases/4.0.0/tools/lld/docs/ReleaseNotes.html](http://llvm.org/releases/4.0.0/tools/lld/docs/ReleaseNotes.html)

Thanks to everyone who helped with filing, fixing and code reviewing  
for release blocking bugs.

Special thanks to the release testers and packagers: Ben Pope,  
Bernhard Rosenkränzer, Diana Picus, Dimitry Andric, Mehdi Amini,  
Michał Górny, Renato Golin, Simon Dardis, and Sylvestre Ledru. Also  
thanks to Zhendong Su and his team whose fuzz testing prevented many  
bugs going into the release.

For questions or comments about this release, please contact the  
community on the mailing lists. Onwards to LLVM 5!

Cheers,  
Hans

---

<div class="post-metadata">

### Author: ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [March 14, 2017, 2:53am UTC](https://discourse.julialang.org/t/progress-with-julia-codegen-and-llvm-4-0/2650/2 "2017-03-14T02:53:17Z")

</div>

AFAICT `__vectorcall` is a C feature. Such feature already exists in LLVM and we’ve been using it for a long time. The linker getting stablized could be useful though.

> [@sc0ttwad3](#):
>
> I’m wondering if prior major LLVM releases made significant gains in performance?

In the past few releases, in general there’re both runtime improvements and regressions and always compile time regression. We are already carrying patches for fixes of performance issues that we can identify. We’ll almost certainly upgrade our LLVM version but not before 0.6 release and not without performance regression tests.

---

<div class="post-metadata">

### Author: ![sc0ttwad3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sc0ttwad3/32/3908_2.png) [@sc0ttwad3](https://discourse.julialang.org/u/sc0ttwad3)
#### Post date: [March 14, 2017, 3:07am UTC](https://discourse.julialang.org/t/progress-with-julia-codegen-and-llvm-4-0/2650/3 "2017-03-14T03:07:57Z")

</div>

Thanks for the clarity on the process and testing before an upgrade (and all the great work on Julia 0.6, btw).

I just found later in the full release notes for LLVM 4 and found where the feature (yes, a C feature) handling was updated/corrected in LLVM, also its original purpose as a feature awhile back:

> Existing \_\_vectorcall calling convention support was extended to include correct handling of HVAs. The \_\_vectorcall calling convention was introduced by Microsoft to enhance register usage when passing parameters.

Thx again.
