RFC: ErLLVM - An LLVM backend for Erlang

Project Infrastructure LLVM Dev List Archives
1

Hi,

We 've been working on an LLVM backend for High Performance Erlang (HiPE) [1],
the native code compiler of Erlang/OTP [2]. ErLLVM [3] targets the X86 and AMD64
architectures for now but there is some ongoing work from a team on the Uppsala
University to also support ARM. In our implementation, we have paid special
attention on retaining ABI-compatibility with the Erlang Runtime System in order
to support loading both HiPE- and ErLLVM-generated code at the same time.

Currently, our work is supported by the Erlang/OTP team and it has reached a
complete and robust state. Thus, we would like to submit some patches to the
LLVM project to support our work on ErLLVM.

Our patches (applied on current Git ToT as of: "5e5c5f8 Rename 'fpaccuracy'
metadata to the more generic 'fpmath'...") involve:

1) A new calling convention (& register pinning as explained in [4]).

Touches:
- include/llvm/CallingConv.h
- lib/Target/X86/X86CallingConv.td
- lib/Target/X86/X86ISelLowering.cpp
- lib/Target/X86/X86RegisterInfo.cpp
&&
- lib/Target/X86/X86RegisterInfo.td

2) A pass to add custom prologue when needed (that performs a stack check and
inserts a call to a BIF, named "inc_stack_0", from the HiPE Runtime to increase
the available stack of a function frame).

Touches/Adds:
- include/llvm/Target/TargetOptions.h
- tools/llc/llc.cpp
&&
- include/llvm/Erlang.h
- include/llvm/Target/TargetFrameLowering.h
- lib/CodeGen/PrologEpilogInserter.cpp
- lib/Target/X86/X86FrameLowering.cpp
- lib/Target/X86/X86FrameLowering.h

3) A GC plugin to support precise Garbage Collection (with the problems
explained in a previous mail [5]).

Touches/Adds:
- include/llvm/ErlangGC/ErlangGCPrinter.h
- lib/ErlangGC/ErlangGC.cpp
- lib/ErlangGC/ErlangGCPrinter.cpp
- lib/ErlangGC/Makefile
- lib/Makefile

The commit messages and the comments in the code should explain a lot; however,
feel free to ask anything that doesn't make any sense for you! :slight_smile:

We 're looking forward to any feedback for the above patches as we would love to
get this included in LLVM so that we don't need to carry around our own version
of LLVM. We are aware that some of the patches might not adhere to the "LLVM
way" of handling things or even include some coding style violations. As Tom
Stellard indicated in his R600 mail too, we didn't want to spend a lot of time
on coding style changes prior to the initial review in case big changes to the
code are needed.

Best regards,
The ErLLVM team

[1]: High-Performance Erlang
[2]: http://www.erlang.org
[3]: http://erllvm.softlab.ntua.gr
[4]: http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt
[5]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-April/048685.html

0001-Implemented-HiPE-Calling-Convention-1-2.patch (9.22 KB)

0002-Implemented-HiPE-Calling-Convention-2-2.patch (1.23 KB)

0003-HiPE-prologue-code-emission-for-X86-as-a-pass-1-2.patch (2.31 KB)

0004-HiPE-prologue-code-emission-for-X86-as-a-pass-2-2.patch (7.65 KB)

0005-A-Garbage-Colleciton-plugin-for-HiPE-s-gc-scheme.patch (12.8 KB)

2

Hi,

Following Chris' advice, I will rebase the patches and break them in 3 distinct
emails (one at a time) in order to be easier for a reviewer to
approve/comments. Please note that the three patches while being code-wise
independent, they 're strongly-connected *semantically*, meaning that including
just a subset of these patches to LLVM's code base is quite weak if the others
are not included also.

Best regards,
Yiannis Tsiouris (as part of the ErLLVM team)

3

This patch (and the others that will follow) are rebased on svn r155440:

"AVX2: The BLENDPW instruction selects between vectors of v16i16 using an i8
immediate. We can't use it here because the shuffle code does not check that
the lower part of the word is identical to the upper part"

Patch 1/3:

The attached commits add a new calling convention to support the LLVM backend
for HiPE compiler, as described in a previous email. The corresponding commit
messages are:

0001:

Implemented a new calling convention (cc 11) for HiPE similar to GHC's cc 10.
In detail:
* Inserted new symbol "cc 11" (CallingConv::HiPE).
* Created cc and retcc for both 32 and 64 bit.
* HiPE cc defines no calleE-save registers.
* HiPE cc supports tail call optimization.

0002:

Hack fix for GR32_TC registers.
Add EBX, EDI to GR32_TC register class to handle a "ran out of registers during
register allocation" in case of tailcall existance because in EAX, ECX, EDX
are all argument registers in HiPE CC.

Regards,
Yiannis

0001-Implemented-HiPE-Calling-Convention-1-2.patch (8.13 KB)

0002-Implemented-HiPE-Calling-Convention-2-2.patch (689 Bytes)

4

This patch (and the others that will follow) are rebased on svn r155440:

"AVX2: The BLENDPW instruction selects between vectors of v16i16 using an i8
  immediate. We can't use it here because the shuffle code does not check that
  the lower part of the word is identical to the upper part"

Patch 1/3:

The attached commits add a new calling convention to support the LLVM backend
for HiPE compiler, as described in a previous email. The corresponding commit
messages are:

We understand that the LLVM developers may be busy, but any chance that we will get some reaction on this patch soon?

A five minute look at the changes in this patch will most probably reveal that the changes are non-intrusive and non-controversial and will allow us to proceed further in discussing the next two parts of the patch we would like to submit.

Thanks in advance,

Kostis Sagonas (for the ErLLVM team)

5

Hi Kostis,

Just to check, did you send the patch originally to llvmdev or llvm-commits?
The latter is where all commit review takes place.

Cheers,

James

6

Hi Kostis,

Just to check, did you send the patch originally to llvmdev or llvm-commits?
The latter is where all commit review takes place.

We've sent them to llvmdev only but the subject was clearly marked with an RFC. Actually, the original post had all of the sets of patches in one mail and Chris Lattner, in a private mail, suggested that perhaps that was the reason why there were being ignored by the community.

We decided to broke the patches into three smaller chunks and start with the one that, in our opinion at least, is the clearly non-intrusive and easier to see that it's "trivial to merge".

We can (re-)submit this patch to llvm-commits too. We'll do this today.

Best and thanks for the reaction,

Kostis