[LLVMdev] C Backend Ressurected
Carback, Richard T., III
rcarback at draper.com
Tue Aug 19 12:08:33 PDT 2014
It provides a useful starting point, but I agree with Jim that it is not a complete solution and requires rework of the results in a lot cases. I think we could improve it further to address these issues but that work is nontrivial.
If you are deciding between a quick and dirty implementation of a custom backend vs. the C backend, then the C backend is sometimes preferable in my experience although it depends on the complexity of the code you are trying to run and how often you need to change it.
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jim Grosbach
Sent: Tuesday, August 19, 2014 2:12 PM
To: Bruce Hoult
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] C Backend Ressurected
This is part of the problem with the C backend. This is very much not what it’s useful for, yet it very much looks like it is. The LLVM IR is target dependent, including things like structure layout, pointer size, and other ABI issues. Even with a resurrected C backend, you can’t use it as a substitute for real target support.
-Jim
On Aug 18, 2014, at 7:02 PM, Bruce Hoult <bruce at hoult.org<mailto:bruce at hoult.org>> wrote:
I don't know how good it is, but the applications seem obvious. e.g. compiling programs in any of a number of original formats to run natively on CPUs that have a working simple C compiler (maybe only K&R or C89) but don't have an LLVM back end.
The source program could be in modern C, C++, or any other high level language or assembly language with a translator to LLVM.
On Tue, Aug 19, 2014 at 1:40 PM, Jun Koi <junkoi2004 at gmail.com<mailto:junkoi2004 at gmail.com>> wrote:
On Mon, Aug 18, 2014 at 9:18 PM, Carback, Richard T., III <rcarback at draper.com<mailto:rcarback at draper.com>> wrote:
Hi All,
2 of my summer interns (Aimee Dipietro and Greg Simpson) used their time over the summer to resurrect the LLVM C Backend:
https://github.com/draperlaboratory/llvm-cbe
Improvements include recovery of simple for/while loops (instead of goto), better variable naming, inline asm support, and making it work on a more recent version of llvm. I believe they used the repository here as a starting point:
https://github.com/glycerine/llvm/tree/cbe_revival
Feedback is welcomed. I would like to see this feature put back into LLVM, and any help on how to make that happen would be appreciated.
would you mind explaining what this backend is for, and its applications?
i guess it is to get the C code at the output of the backend, but dont get why we need it.
thanks,
Jun
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu<http://llvm.cs.uiuc.edu/>
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140819/e9fe6990/attachment.html>
More information about the llvm-dev
mailing list