similar to: [LLVMdev] Question about SPARC target status

On Nov 10, 2008, at 8:09 AM, Peter Shugalev wrote: > Hello, > > I've noticed SPARC target lacks some of functionality (only asm > printer > is implemented with no binary code emitter and no 64-bit ABI support). > > Are there any (probably uncommited) advances in these areas? The most > needed feature for me is sparc64 support. If I decide to implement > these

Anton Korobeynikov wrote: > And fix 32 bit ones :) Mostly byval stuff + FP arguments. How serious these bugs are? Any link to bug descriptions? Is LLVM sparc target usable and stable in case of not using any FP stuff? -- Best Regards Peter Shugalev

On Tue, 11 Nov 2008, Peter Shugalev wrote: > Anton Korobeynikov wrote: >> And fix 32 bit ones :) Mostly byval stuff + FP arguments. > > How serious these bugs are? Any link to bug descriptions? Is LLVM sparc > target usable and stable in case of not using any FP stuff? > There are usually two levels of translation that go on. First, your C/C++ code is compiled to LLVM IR

Hi, > but haven't had time (or machines) to do further development. I would > love to see someone add 64-bit ABI and JIT support. I don't know of And fix 32 bit ones :) Mostly byval stuff + FP arguments. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Nov 11, 2008, at 3:51 PM, Peter Shugalev wrote: > Owen Anderson wrote: >> If you configure it as a cross-compiler for 64-bit x86 Linux and >> feed it >> the appropriate header files, it will produce the same output on any >> platform. However, that output will not be executable on most >> platforms, just on 64-bit x86 Linux. The problems go beyond pointer

On Nov 11, 2008, at 5:11 PM, Peter Shugalev wrote: > Owen Anderson wrote: >> What about something much simpler: memcpy'ing an array of structs >> around. The number of bytes to be memcpy'd is dependent on the >> padding >> of the struct. > > Anyway, I've got your point. sizeof() constant expression is > calculated > during wrong stage of

Hi, Anton Korobeynikov wrote: >> I thought llvm-gcc isn't meant to compile for specific target (at least >> with -emit-llvm flag I'm using). > No, it is not. C language is highly target-specific, thus LLVM IR > obtained from such sources also has the same nice 'property' I can see only one reason for such dependence: inclusion of system headers in /usr/include.

On Nov 11, 2008, at 10:34 AM, Peter Shugalev wrote: > Hi, > > Anton Korobeynikov wrote: >>> I thought llvm-gcc isn't meant to compile for specific target (at >>> least >>> with -emit-llvm flag I'm using). >> No, it is not. C language is highly target-specific, thus LLVM IR >> obtained from such sources also has the same nice

Hi, Luke K. Dalessandro wrote: > llvm-gcc isn't prepared to compile for a SPARC target. This includes lack > of complete FP support, and no implementation of the SPARC ABI which means > that function arguments aren't passed correctly and you probably can't > call any precompiled code that assumes the SPARC ABI. I will be working on > fixing this for sparc-solaris,

On Nov 11, 2008, at 2:19 PM, Peter Shugalev wrote: > Hi, > > Owen Anderson wrote: >>> I can see only one reason for such dependence: inclusion of system >>> headers in /usr/include. If I compile llvm-gcc with predefined set >>> of >>> Linux headers (the way cross-compilers are usually made) will the IR >>> output be the same no matter which

Owen Anderson wrote: > What about something much simpler: memcpy'ing an array of structs > around. The number of bytes to be memcpy'd is dependent on the padding > of the struct. Anyway, I've got your point. sizeof() constant expression is calculated during wrong stage of compilation process. Thanks for pointing it out! -- Best Regards Peter Shugalev

Hi, Chris Lattner wrote: > Yes, not to mention stuff like: > > #ifdef __i386__ > > or: > case sizeof(foo): > > This is addressed here: > http://llvm.org/docs/tutorial/LangImpl8.html#targetindep > > Note that this doesn't affect cross compilation: you just need to > configure llvm-gcc as a proper cross compiler. This just means that > llvm

Hi, Owen Anderson wrote: >> I can see only one reason for such dependence: inclusion of system >> headers in /usr/include. If I compile llvm-gcc with predefined set of >> Linux headers (the way cross-compilers are usually made) will the IR >> output be the same no matter which platform is used for compilation? >> > > No. Consider use of sizeof(), ABI issues,

Owen Anderson wrote: > If you configure it as a cross-compiler for 64-bit x86 Linux and feed it > the appropriate header files, it will produce the same output on any > platform. However, that output will not be executable on most > platforms, just on 64-bit x86 Linux. The problems go beyond pointer > size. The size of int is implementation dependent, etc. The layout and

Chris Lattner wrote: > On Mar 26, 2010, at 6:24 PM, Peter Shugalev wrote: > >> Hi, >> >> Just realized that ability to generate static object code (e.g. ELF w/o >> using JIT) is no longer available in 2.7 (at least in release_27 branch). >> >> For example >>> llc -filetype=obj whatever.bc >> doesn't work in Linux environment anymore

On Tue, 11 Nov 2008, Peter Shugalev wrote: > Hi, > > Anton Korobeynikov wrote: >>> I thought llvm-gcc isn't meant to compile for specific target (at least >>> with -emit-llvm flag I'm using). >> No, it is not. C language is highly target-specific, thus LLVM IR >> obtained from such sources also has the same nice 'property' > > I can see

Hi, Just realized that ability to generate static object code (e.g. ELF w/o using JIT) is no longer available in 2.7 (at least in release_27 branch). For example > llc -filetype=obj whatever.bc doesn't work in Linux environment anymore (well it wasn't fully implemented before but it worked for simple bytecodes in 2.6). I used to generate code by creating TargetMachine and

On Mar 26, 2010, at 6:24 PM, Peter Shugalev wrote: > Hi, > > Just realized that ability to generate static object code (e.g. ELF w/o > using JIT) is no longer available in 2.7 (at least in release_27 branch). > > For example >> llc -filetype=obj whatever.bc > doesn't work in Linux environment anymore (well it wasn't fully > implemented before but it worked

Chris Lattner wrote: > On Mar 27, 2010, at 3:41 AM, Peter Shugalev wrote: > >>>> Now LLVMTargetMachine::addPassesToEmitFile has changed. It adds its own >>>> code emitter and it's always MachOCodeEmitter which of course I don't need. >>>> >>>> Is there a new way to create non-JIT object code in LLVM 2.7? >>> Nope, sorry. This

Hi, > I thought llvm-gcc isn't meant to compile for specific target (at least > with -emit-llvm flag I'm using). No, it is not. C language is highly target-specific, thus LLVM IR obtained from such sources also has the same nice 'property' > Speaking of SPARC ABI can I still call non-FP external (i.e. compiled > with regular non-llvm gcc to native sparc binary)