similar to: [LLVMdev] [RFC] Resurrecting the C back-end

On 27.08.2012 22:56, Roel Jordans wrote: > > Anyway, that brings to my final question: Which features are > critical/important/wanted/unwanted for a C back-end? > I'd like it to be easy to configure (e.g. to tell which size int is assumed to have). I'd prefer the resulting code to not rely on implementation-defined behaviour (e.g. not make any assumptions about the size of

Will this allow users to compile C++ (or some other language that LLVM has a frontend for) to C, which then can be compiled using a C compiler for a target architecture, for which only a C compiler exists? Which use-cases do you have in mind for this backend? Philipp

On 28/08/12 04:30, Philipp Klaus Krause wrote: > Will this allow users to compile C++ (or some other language that LLVM > has a frontend for) to C, which then can be compiled using a C compiler > for a target architecture, for which only a C compiler exists? > Which use-cases do you have in mind for this backend? > Possibly yes, compiling C++ to C would require support for things

Hi Roel, It's good to know that you're working on C backend. But IMO, the reason that C backend was removed in LLVM 3.1 is no one maintain the C backend. If you bring it back, would you like to take the responsibility for the maintaining work? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.)

On 28.08.2012 14:08, Joshua Cranmer wrote: > On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >> I think the C backend also allow people performing source-to-source >> transform with LLVM (instead of Clang). > > I do not believe that this would be the case nor that it should be a > goal. Source-to-source transformation requires a lot of accurate > information about the AST,

On Aug 27, 2012, at 10:39 PM, Philipp Klaus Krause <pkk at spth.de> wrote: > On 28.08.2012 14:08, Joshua Cranmer wrote: >> On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >>> I think the C backend also allow people performing source-to-source >>> transform with LLVM (instead of Clang). >> >> I do not believe that this would be the case nor that it should

On 28.08.2012 14:47, Cameron Zwarich wrote: > On Aug 27, 2012, at 10:39 PM, Philipp Klaus Krause <pkk at spth.de> wrote: > >> On 28.08.2012 14:08, Joshua Cranmer wrote: >>> On 8/27/2012 9:57 PM, Hongbin Zheng wrote: >>>> I think the C backend also allow people performing source-to-source >>>> transform with LLVM (instead of Clang). >>>

I think the C backend also allow people performing source-to-source transform with LLVM (instead of Clang). ether On Tue, Aug 28, 2012 at 10:30 AM, Philipp Klaus Krause <pkk at spth.de> wrote: > Will this allow users to compile C++ (or some other language that LLVM > has a frontend for) to C, which then can be compiled using a C compiler > for a target architecture, for which only

On 8/27/2012 9:57 PM, Hongbin Zheng wrote: > I think the C backend also allow people performing source-to-source > transform with LLVM (instead of Clang). I do not believe that this would be the case nor that it should be a goal. Source-to-source transformation requires a lot of accurate information about the AST, and conversion to LLVM IR is way too lossy. Signedness, for example, is

Hi Arnold, On 06/12/12 08:50, 陳韋任 (Wei-Ren Chen) wrote: > On Thu, Dec 06, 2012 at 10:05:03AM +0800, Mingliang LIU wrote: >> Hi Arnold, >> >> Thank you. I googled but missed the release notes. >> >> Regards. > > Someone else out there tried to bring cbe back. You can search the ML > archieve and reach them out. > That would be me. > Regards,

Hi, I have a version of the old CBackend which is working with the current trunk. I am in the progress of rewriting it into a new version but that project is not going as fast as I would hope as I have been distracted by other tasks with higher priority lately. Anyway, for those interested, I can provide patches, optionally separated into several parts (core, testing, misc). I am afraid that

I'm very interested in this patch. Could you, Roel, upload it somewhere or maybe put your code to github or something simmilar? Additional - you're fixing it - could you please provide a little more information - what should I read to get more informations about writing not hardware but software backend in LLVM? (Of course the code analysis is one way, but maybe there is other also).

Hello all, When going through the internals of the old C back-end, I see that the CBE encapsulates arrays into a struct. The source code has the following comment to explain this behaviour. // Arrays are wrapped in structs to allow them to have normal // value semantics (avoiding the array "decay"). For example, the CBE translates: @a = common global [10 x i32]

Hi Duncan, On 11/10/12 15:47, Duncan Sands wrote: > Hi Roel, > >> When going through the internals of the old C back-end, I see that the CBE >> encapsulates arrays into a struct. The source code has the following comment to >> explain this behaviour. >> >> // Arrays are wrapped in structs to allow them to have normal >> // value semantics

Hi,all: i have a question about llvm162227,recently i have a work about cBackend,i found a the Module data is different from llvm2.9,a pass named CBackendNameAllUsedStructsAndMergeFunctions() was removed.for this the module data can not be translated correctly. when i try to rewrite this pass,i found much interfaces of module have been changed. i write a test which contian a struct like this

I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. It works on arguments because they can be given the 'noalias' attribute, and then the alias analyzer must understand what that means. Pete On Jan 24, 2012, at 7:47 AM, Roel Jordans wrote: > I have no clue, I didn't have time to look into that example yet.

For those wondering about the C backend, a patch(set) to current trunk is available but too large to send through the LLVM mailinglist. I can send the patch(es) directly if people are interested. Cheers, Roel On 17/11/12 03:48, David Claughton wrote: > Hi Roel, > > On 13/09/12 11:02, Roel Jordans wrote: >> >> For those that are interested, I can provide a patch to the

On 17-03-17 22:34, Mehdi Amini wrote: >> On Mar 17, 2017, at 12:39 PM, Roel Jordans via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I have a question related to GSoC. One of my students submitted an idea [1] for a GSoC project and I would be interested in (co-)mentoring this project but I'm unsure of the qualification requirements for

If you want to get the original name by a library function, as Jonathan mentioned, you can call __cxa_demangle in cxxabi.h. However, this API is only available in gcc. If you want something more portable, try glog or libibert, notice libibert is GPL licensed. On Thu, Dec 11, 2014 at 7:57 AM, Roel Jordans <r.jordans at tue.nl> wrote: > When a C++ compiler translates source code it will

Can you explain please why it works for this version of the function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z); What is different here? There are stores here as well. Brent On Wed, Jan 25, 2012 at 12:34 AM, Roel Jordans <r.jordans at tue.nl> wrote: > Hi Brent, > > I think this is a problem in the easy-cse transform. In this transform