[llvm-commits] [RFC] Patch 1/3 for the native code compiler of Erlang

Yiannis Tsiouris gtsiour at softlab.ntua.gr
Wed May 2 13:26:01 PDT 2012


Hi Jakob,

On 05/02/2012 09:42 PM, Jakob Stoklund Olesen wrote:
> On May 2, 2012, at 10:36 AM, Yiannis Tsiouris <gtsiour at softlab.ntua.gr> wrote:
>
>> 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.
> Please add test cases.
Sorry for that! I must have missed the "--new-file" when using diff...
The attached commit includes the tests (based on ghc-cc/ghc-cc64.ll).

>> 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 existence
>> | because in EAX, ECX, EDX are all argument registers in HiPE CC.
> You can't just change GR32_TC to make an assertion go away. Those registers must not be callee-saved, they are used to hold the address of the function jumped to in a dynamic tail call.
>
> How does a dynamic tail call work when all registers are callee-saved?
The error without this dirty fix is:

> "LLVM ERROR: ran out of registers during register allocation"

And it only happens in 32-bit mode. I'm not sure which assertion exactly
is the one that you refer to.

The problem is that EAX, ECX and EDX are all registers that are involved
in argument passing (ARG0, ARG1, ARG2 actually). Thus, when a tailcall
needs more than 2 arguments there remains no register to be used for
holding the address of the dynamic tail call (as they are the only ones
in GR32_TC register class). We were not sure how we should attack this
problem, that's why we followed the approach of HiPE and added two more
registers  (not involved anywhere else in the HiPE CC).

What do you think we should do for that? Shouldn't the registers
involved in this class be somehow co-related with the user-defined
calling conventions? I hope there is a solution that doesn't involve
creating a new Codegen target!

Thanks for your comments,
Yiannis

-- 
Yiannis Tsiouris
Ph.D. student,
Software Engineering Laboratory,
National Technical University of Athens
WWW: http://www.softlab.ntua.gr/~gtsiour

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Implemented-HiPE-Calling-Convention-1-2.patch
Type: text/x-diff
Size: 11879 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120502/c0b6498e/attachment.patch>


More information about the llvm-commits mailing list