similar to: [LLVMdev] CBE progress and design

Hello all, As some of you may remember, I am trying to get the C back-end back in working condition. I have the old version up and running (including most of it's pre-existing bugs), email me if you want a patch to the current trunk. === Question 1: new design feedback === I am currently looking into moving the CBE to run after the initial lowering and type legalization phases so that

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 Arnold, Thank you. I googled but missed the release notes. Regards. On Thu, Dec 6, 2012 at 12:13 AM, Arnold Schwaighofer < arnold.schwaighofer at gmail.com> wrote: > The C Backend was remove in 3.1 > (http://llvm.org/releases/3.1/docs/ReleaseNotes.html): > > "Major Changes and Removed Features > ... > The C backend has been removed. It had numerous problems,

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

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]

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. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.)

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

I'm having some trouble using bugpoint with newer version of gcc (bugpoint debug output below). I looked into the "conflicting type for malloc" problem and it doesn't seem easy to solve due to the unknown size of size_t (see LowerAllocations.cpp). The "void main()" problem is probably a result of this test being converted from Fortran. I'll have to dig into

On Wednesday 16 July 2008 10:31, David Greene wrote: > On Wednesday 16 July 2008 10:12, David Greene wrote: > > I'm having some trouble using bugpoint with newer version of gcc > > (bugpoint debug output below). > > I was using gcc 4.1.2. When I try 3.2.3 I get: > > bugpoint-test-program.bc.cbe.c:237: warning: conflicting types for built-in > function

Hi, I'm running into some strange errors with the CBE. I've narrowed the problem down to a very simple CPP program: main.cpp: -------------------------------------------------------------------------------- #include <string> static std::string hello("Hello world!"); int main() { return 0; }

On Wed, Nov 21, 2012 at 1:53 AM, Roel Jordans <r.jordans at tue.nl> wrote: > 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. > That *is* interesting. I suppose you could use any of the number of free file/snippet/paste upload

On Wednesday 16 July 2008 10:12, David Greene wrote: > I'm having some trouble using bugpoint with newer version of gcc (bugpoint > debug output below). I was using gcc 4.1.2. When I try 3.2.3 I get: bugpoint-test-program.bc.cbe.c:237: warning: conflicting types for built-in function `memcpy' bugpoint-test-program.bc.cbe.c: In function `main':

I will definately look into this tonight and see if it is a problem with my recent patch. On Wednesday 02 March 2005 3:39 am, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > > On Tue, 2005-03-01 at 22:07, Markus F.X.J. Oberhumer wrote: > >>Follow up: After removing the dangling symlink the problem now looks: > >> > >>-march=c((anonymous

On Tue, 2005-03-01 at 22:07, Markus F.X.J. Oberhumer wrote: > Follow up: After removing the dangling symlink the problem now looks: > > -march=c((anonymous namespace)::PrintStackTrace()+0x1e)[0x847a17e] > -fno-strict-aliasing: example.out.cbe.c: No such file or directory > gccld: example.out.cbe.c: Can't destroy file: > make: *** [example.out] Error 1 > At a minimum that

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 (avoiding the array "decay"). > > For example, the CBE translates: >

The C Backend was remove in 3.1 (http://llvm.org/releases/3.1/docs/ReleaseNotes.html): "Major Changes and Removed Features ... The C backend has been removed. It had numerous problems, to the point of not being able to compile any nontrivial program." On Wed, Dec 5, 2012 at 10:00 AM, Mingliang LIU <liuml07 at gmail.com> wrote: > Hi all, > > I met an error when I run the

Hi all, I met an error when I run the llc command to transform a bitcode file to C code (source to source): $ llc -march=c -o foo.c foo.ll However, it said "*llc: error: invalid target 'c'.*" I checked the 'llc --version' only to find that there is no *c* as target. The *cpp* was there, which makes calls against the LLVM C++ API. But that's not what I want. I

*> Chris Lattner**, Mon Nov 15 12:06:18 CST 2010, wrote: **> *> If anyone was really interested in this, I'd strongly suggest a complete rewrite of the C backend: make use the existing target independent code generator code (for legalization etc) and > then just put out a weird ".s file" at the end. -Chris I see that Chris made the above suggestion a while ago. Are

On Wed, Jul 16, 2008 at 9:00 AM, David Greene <dag at cray.com> wrote: > What's the proper incantation to get bugpoint to run things through opt > but use llc to generate asm? As noted, CBE has issues generating > correct code so using it isn't an option right now. It should be something like bugpoint x.bc -llc-safe -pass1 -pass2 -pass3. The -llc-safe forces it to never

Hello, David. > After hacking around in the CBE output I managed to compile it with > gcc, only to discover that gcc 4.1.2 has the SAME bug LLVM does with > respect to alignment. Automatic stack realignment was atted to X86 backend ~3 months ago. Everything should work with LLVM. If not - please fill out a PR. AFAIR, automatic stack realignment still does not land into gcc mainline