similar to: [LLVMdev] How to use llvm to cross-compile to C

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). >>>

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: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,

I want to use llvm to develop for an embedded system. Ther is a free C compiler targeting the embedded system. I hope llvm will provide a way to use other languages, e.g. using clang to compile C++. How can I do this? How do I tell llvm the size of ints on the target, etc? Philipp

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

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

Even though wine versions get released often and the weekly newsletters seem to report progress I get the impression that wine is not really improving. Of course it happens that some applications work with newer wine versions which didn't work with older ones, but at the same time old applications stop working. Is it only me that gets the impression that wine only changes over time, but

Warning: Sligthly off topic. http://shelleytherepublican.com/2006/04/linux-european-threat-to-our-computers.html Quotes: > And guess what software Osama Bin Laden uses on his laptop? > > If you guessed it was Linux you would be 100% right. > Next time somebody asks you how Al Queda agents pay for their > rifles and rocket launchers, you can tell them that foreign hackers >

Hello all, I am in need for a working C back-end for LLVM for my current research. I know that the previous incarnation of this back-end has been kicked out of the tree since the 3.1 release and I have gone through the archives to restore it to it's previous 'glory'. So far, I have restored most of the previous version (excluding some of the parts that needed changes outside of

Hi Philipp, On Fri, 2006-11-24 at 20:09 +0100, Philipp Klaus Krause wrote: > Reid Spencer schrieb: > > > Note that C and LLVM types are *not* the same things (despite the > > similar names). We are in the process of making this abundantly clear. > > The LLVM IR will soon use names like i8, i16, i32, and i64 (signless > > integer quantities of specific sizes,

Reid Spencer schrieb: > Hi Philipp, > > On Fri, 2006-11-24 at 20:09 +0100, Philipp Klaus Krause wrote: >> Reid Spencer schrieb: >> >>> Note that C and LLVM types are *not* the same things (despite the >>> similar names). We are in the process of making this abundantly clear. >>> The LLVM IR will soon use names like i8, i16, i32, and i64 (signless

On Thu, 2006-11-23 at 19:10 +0100, Philipp Klaus Krause wrote: > Pertti Kellomäki schrieb: > > Chris Lattner wrote: > >> Many aspects of the target compiler can leak through. > > > > So if one wants to use the LLVM system as a cross compiler, one > > has to configure llvm-gcc as a cross compiler? Fair enough, I guess. > > I hope the C backend is still

Reid Spencer schrieb: > On Thu, 2006-11-23 at 19:10 +0100, Philipp Klaus Krause wrote: >> Pertti Kellomäki schrieb: >>> Chris Lattner wrote: >>>> Many aspects of the target compiler can leak through. >>> So if one wants to use the LLVM system as a cross compiler, one >>> has to configure llvm-gcc as a cross compiler? Fair enough, I guess. >> I

Pertti Kellomäki schrieb: > Chris Lattner wrote: >> Many aspects of the target compiler can leak through. > > So if one wants to use the LLVM system as a cross compiler, one > has to configure llvm-gcc as a cross compiler? Fair enough, I guess. I hope the C backend is still meant to generate portable code though. Philipp

Reid Spencer schrieb: > Note that C and LLVM types are *not* the same things (despite the > similar names). We are in the process of making this abundantly clear. > The LLVM IR will soon use names like i8, i16, i32, and i64 (signless > integer quantities of specific sizes, regardless of platform). I had explicitly specified the size in the input code using a uint32_t type, the

Anton Korobeynikov schrieb: > Hello, Philipp. > >> unsigned is 16 bit on my target platform. > Could you please show LLVM bytecode? > I've attached the .bc file and the .c source and output files. I compiled dusing llvm-gcc (not configured as cross-compiler though, so that might be the problem). Nevertheless I don't really see why portable source shouldn't be

On Thu, 2006-11-23 at 21:09 +0100, Philipp Klaus Krause wrote: > Reid Spencer schrieb: > > It generates C99. Its portability is no better or worse than any other > > backend. > > Does that mean that I will have to configure llvm as a cross-compiler > even when using the C backend? LLVM doesn't need to be configured as a cross compiler. It can generate code for a

On Fri, 2006-11-24 at 21:13 +0100, Philipp Klaus Krause wrote: > Reid Spencer schrieb: > Hmm the problem was a bit different. I just reproduced it. > > I used this input file: > > #include <stdint.h> > > uint32_t test(uint32_t t) > { > return(t + 42); > } > > and got the following code: > > unsigned test(unsigned ltmp_0_1) { > return

Reid Spencer schrieb: > hat you do need to do > is configure your front end to be a cross compiler. Then it will > generate the correct LLVM input for that platform (and consequently LLVM > will generate code for that platform) regardless of the platform on > which either LLVM or your front end are running. > Is that needed for thing like sizeof() and size of native datatypes

I tried llvm-gcc -c test.c llvm-gcc test.o llc -march=c test.bc -f -o test2.c Then I compiled both test.c and test2.c with sdcc, a compiler which lacks high-level optimization. The code generated from test2.c was bigger. Then I tried llvm-gcc -O5 -Os -c test.c llvm-gcc -O5 -Os test.o llc -march=c test.bc -f -o test2.c But it generated exactly the same code as the commands above. What is it that