# Julia LLVM projects?

**URL:** <https://discourse.julialang.org/t/julia-llvm-projects/1349>\
**Category:** Internals & Design\
**Created:** [January 7, 2017, 10:46pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349 "2017-01-07T22:46:06Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Phil\_Tomson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phil_tomson/32/3575_2.png) [@Phil\_Tomson](https://discourse.julialang.org/u/Phil_Tomson)\
**Post date:** [January 7, 2017, 10:46pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/1 "2017-01-07T22:46:06Z")

</div>

I just finished up an LLVM contract porting to a new processor architecture, I’ve got a bit of free time and was wondering where I might find a list of LLVM-related items/projects that need attention in Julia. I looked at the github projects, but didn’t see anything in that category. I’d primarily be interested in backend as opposed to frontend projects mainly because that’s where my experience is, but I’d be open to either.

Phil

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 7, 2017, 11:16pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/2 "2017-01-07T23:16:48Z")

</div>

Most of the LLVM-related stuff is in Julia itself, e.g. you can search through the Julia issues for LLVM topics such as:

[https://github.com/JuliaLang/julia/issues/19654](https://github.com/JuliaLang/julia/issues/19654)  
[https://github.com/JuliaLang/julia/issues/19640](https://github.com/JuliaLang/julia/issues/19640)  
[https://github.com/JuliaLang/julia/pull/19342](https://github.com/JuliaLang/julia/pull/19342)

The main LLVM-related packages are probably Cxx ([GitHub - JuliaInterop/Cxx.jl: The Julia C++ Interface](https://github.com/Keno/Cxx.jl)), Gallium ([https://github.com/Keno/Gallium.jl](https://github.com/Keno/Gallium.jl)), and maybe some of the GPU packages?

---

<div class="post-metadata">

**Author:** ![johnmyleswhite](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnmyleswhite/32/31_2.png) [@johnmyleswhite](https://discourse.julialang.org/u/johnmyleswhite)\
**Post date:** [January 7, 2017, 11:27pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/3 "2017-01-07T23:27:46Z")

</div>

People frequently express interest in generating webassembly via LLVM. Perhaps that’s another possible project for someone with existing LLVM expertise?

---

<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:** [January 7, 2017, 11:41pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/4 "2017-01-07T23:41:42Z")

</div>

There are also more LLVM specific issues that affects julia. Those require less knowledge of julia so it might be easier for you to get started. Unfortunately, those aren’t always searchable on our issue tracker (we currently don’t always keep an issue open for upstream issue).

Here’s a list of LLVM backend bugs that affect us.

X86 partial register stall:  
(In general)  
[https://llvm.org/bugs/show\_bug.cgi?id=25277](https://llvm.org/bugs/show_bug.cgi?id=25277)  
AVX only (doesn’t happen with SSE) (There doesn’t seem to be a LLVM bug report for this)  
[https://github.com/JuliaLang/julia/pull/19259#issuecomment-270640272](https://github.com/JuliaLang/julia/pull/19259#issuecomment-270640272)

Code generation bug on X86:  
[https://github.com/JuliaLang/julia/issues/17288](https://github.com/JuliaLang/julia/issues/17288)  
[https://llvm.org/bugs/show\_bug.cgi?id=21183](https://llvm.org/bugs/show_bug.cgi?id=21183)  
We have to work around it. There are better workaround that we might want to implement regardless but it would be nice if we don’t need to worry about this…

Performance issues that we have to workaround on non-X86  
[https://llvm.org/bugs/show\_bug.cgi?id=27545](https://llvm.org/bugs/show_bug.cgi?id=27545)

Yet another limitation on ARM and PPC64  
[https://llvm.org/bugs/show\_bug.cgi?id=28459](https://llvm.org/bugs/show_bug.cgi?id=28459)

---

<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:** [January 7, 2017, 11:47pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/5 "2017-01-07T23:47:19Z")

</div>

Also, note that I just listed all the LLVM bugs affecting us that I know and realized that almost all of them are backend issues… It’s probably not surprising since we deal with the LLVM IR more and it’s much easier to deal with (we don’t expose machine IR in julia and we don’t control machine IR passes at all).

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [January 8, 2017, 3:36am UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/6 "2017-01-08T03:36:25Z")

</div>

Should some of these be added to the [GSoC list](http://julialang.org/soc/ideas-page)? I think we should start readying it for another summer. (Or maybe some of these are too difficult? I don’t know this stuff so I’ll defer to your judgement)

---

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [January 8, 2017, 8:47am UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/7 "2017-01-08T08:47:52Z")

</div>

There is also [LLVM.jl](https://github.com/maleadt/LLVM.jl) (created to support [CUDAnative.jl](https://github.com/JuliaGPU/CUDAnative.jl)) which wraps the C API in an idiomatic, “julian” way. It’s pretty incomplete, only serving my needs for now. Not really LLVM development, but I figured I mentioned it anyway.

---

<div class="post-metadata">

**Author:** ![barche](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/barche/32/79_2.png) [@barche](https://discourse.julialang.org/u/barche)\
**Post date:** [January 8, 2017, 10:12pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/8 "2017-01-08T22:12:40Z")

</div>

Not sure if it’s relevant here, but there is also a [version conflict](https://github.com/JuliaLang/julia/issues/19606) when multiple versions of LLVM get loaded dynamically.

---

<div class="post-metadata">

**Author:** ![Phil\_Tomson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phil_tomson/32/3575_2.png) [@Phil\_Tomson](https://discourse.julialang.org/u/Phil_Tomson)\
**Post date:** [January 9, 2017, 7:13pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/9 "2017-01-09T19:13:02Z")

</div>

I notice the first one was reported in LLVM 3.7. What version of LLVM will Julia use for 0.6? I ask in case this has been fixed in a later version - I think 4.0 is soon to be released.

---

<div class="post-metadata">

**Author:** ![Phil\_Tomson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phil_tomson/32/3575_2.png) [@Phil\_Tomson](https://discourse.julialang.org/u/Phil_Tomson)\
**Post date:** [January 9, 2017, 7:13pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/10 "2017-01-09T19:13:03Z")

</div>

There’s a webassembly target in the current master branch of LLVM: [llvm/lib/Target/WebAssembly at master · llvm-mirror/llvm · GitHub](https://github.com/llvm-mirror/llvm/tree/master/lib/Target/WebAssembly)

I’d guess this is slated for the LLVM 4.0 release.

What would the usage look like in the Julia context? Command line argument to julia? (ie. julia -emit-webassembly)

---

<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:** [January 9, 2017, 11:03pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/11 "2017-01-09T23:03:43Z")

</div>

> [@Phil\_Tomson](#):
>
> What version of LLVM will Julia use for 0.6

3.9.1

Someone seems to have recently started working on it. Not sure if the work covers the avx only case though.

---

<div class="post-metadata">

**Author:** ![o314](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/o314/32/252_2.png) [@o314](https://discourse.julialang.org/u/o314)\
**Post date:** [March 11, 2017, 12:15am UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/12 "2017-03-11T00:15:37Z")

</div>

And now, since a few days, **WebAssembly** has reached the “WebAssembly Consensus status”

Majors supporters say:

- binary version is frozen to 0x1
- no more feature (or always be backward compatible)
- clean up docs and w3c wg charter
- not a preview version anymore. deploy, deploy, deploy

[http://webassembly.org/roadmap/](http://webassembly.org/roadmap/)

Effectively, there is already a webassembly codegen backend at llvm

[https://github.com/llvm-mirror/llvm/tree/master/test/CodeGen/WebAssembly](https://github.com/llvm-mirror/llvm/tree/master/test/CodeGen/WebAssembly)

I personnaly will be very pleased to forget asap javascript in profit of julia on the web client side 🙂

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [March 13, 2017, 4:42pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/13 "2017-03-13T16:42:32Z")

</div>

The way to approach this is to port Julia’s dependencies to WebAssembly – or replace them somehow. Getting LLVM to compile itself to wasm is the very first step. This may already work; if not it’s a very natural next move for the wasm backend. Then one needs to figure out what to do about dependencies like BLAS which have native assembly code in them. Once all dependencies are ported, replaced or removed, compiling Julia itself should be straightforward.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [March 13, 2017, 4:48pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/14 "2017-03-13T16:48:02Z")

</div>

> [@StefanKarpinski](#):
>
> Then figure out what to do about dependencies like BLAS that have native assembly code in them.

If linear algebra is moved out to “default packages”, then couldn’t a wasm version just be built to not have the extra dependencies and use the linear algebra fallbacks? It’ll drop a little bit of speed but would be usable. That might be the easiest way to get this done.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [March 13, 2017, 4:50pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/15 "2017-03-13T16:50:00Z")

</div>

Sure, those are possible solutions: writing BLAS routines in Julia is an option; moving linear algebra stuff out of Base Julia is also an option. That’s why I said “figure out what to do about” rather than “port OpenBLAS” – since porting it seems like the hardest path.

---

<div class="post-metadata">

**Author:** ![o314](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/o314/32/252_2.png) [@o314](https://discourse.julialang.org/u/o314)\
**Post date:** [March 13, 2017, 5:04pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/16 "2017-03-13T17:04:24Z")

</div>

I spend some times last weeks trying to understand the structure of the codebase.  
i believe it could help a lot to harden the modularity in this kind of situation.

here is a draft of the remap i have sketched :

```
./src <- julialang/julia-runtime
./doc/devdocs <- julialang/julia-runtime-doc
./base <- julialang/julia-stdlib
./doc/stdlib <- julialang/julia-stdlib-doc
./test <- julialang/julia-stdlib-test ?
./doc <- julialang/julia-doc
./src/support <- julialang/julia-libcshim
./src/flisp <- julialang/femtolisp
./deps <- julialang/3rd
./contrib <- julialang/sandbox
./examples <- julialang/examples
./etc <- ?
./ui <- ?

```

This help to spot well performing vs weak assembly.  
A lot of good parts appears there. 3 weakness imho: lack of femtolisp test, runtime test, femtolist doc

We do not need absolutely to move on to git submodule yet. All these kinda of work could be simultate with proper subdirectories discipline. Next point should be to reflect the change in the make file.  
We could later decide more simply where to plug bias

I’m still a newbie with the julia codebase and my viewpoint could be a rough approximation of reality for now.

---

<div class="post-metadata">

**Author:** ![Dan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dan/32/42581_2.png) [@Dan](https://discourse.julialang.org/u/Dan)\
**Post date:** [March 14, 2017, 1:48pm UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/17 "2017-03-14T13:48:51Z")

</div>

A hot project for Julia/LLVM would be to manage to run TensorFlow aot (ahead-of-time) compiled XLA code. This came out with version 1.0 of TensorFlow (a few weeks ago) and according to description allows compiling computation graphs into standalone code using LLVM. This opens up the possibility of integrating TF more tightly with Julia.

Apparantly TF is turning slowly into a Julia clone ;), but TF does have a h-u-g-e dev base which would allow Julia to ride along the Deep- hype.

---

<div class="post-metadata">

**Author:** ![Benoit9](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/benoit9/32/690_2.png) [@Benoit9](https://discourse.julialang.org/u/Benoit9)\
**Post date:** [March 16, 2017, 9:50am UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/18 "2017-03-16T09:50:41Z")

</div>

I just came across this tweet by @viralbshah

> I look forward to [#ethereum](https://twitter.com/hashtag/ethereum?src=hash) contracts in [#julialang](https://twitter.com/hashtag/julialang?src=hash) then! [https://t.co/J916x8xX0G](https://t.co/J916x8xX0G)
> 
> — Viral B. Shah (@Viral\_B\_Shah) [July 29, 2016](https://twitter.com/Viral_B_Shah/status/759106812142505984)

 

It would be very cool to have a kind of “ETHnative” package to write Ethereum smart contracts in Julia.

I am no expert, but I believe the inspection and meta-programming capabilities of Julia would be very useful in that context, much like the CUDAnative package for CUDA kernels.

---

<div class="post-metadata">

**Author:** ![fengyang.wang](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fengyang.wang/32/104_2.png) [@fengyang.wang](https://discourse.julialang.org/u/fengyang.wang)\
**Post date:** [March 17, 2017, 1:10am UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/19 "2017-03-17T01:10:52Z")

</div>

I would guess that unfortunately standard Julia code will generally compile into resulting native code that is too large to be useful for Ethereum, from my limited understanding of Ethereum. That would mean that, like CUDAnative, only a subset of Julia might be practical.

---

<div class="post-metadata">

**Author:** ![Benoit9](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/benoit9/32/690_2.png) [@Benoit9](https://discourse.julialang.org/u/Benoit9)\
**Post date:** [March 17, 2017, 7:32am UTC](https://discourse.julialang.org/t/julia-llvm-projects/1349/20 "2017-03-17T07:32:10Z")

</div>

Yes, and I believe that would be fine.

[Next page](https://discourse.julialang.org/t/julia-llvm-projects/1349.md?page=2)