Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Question about SPARC target status"
2008 Nov 10
0
[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
2008 Nov 11
0
[LLVMdev] Question about SPARC target status
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
2008 Nov 11
3
[LLVMdev] Question about SPARC target status
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
2008 Nov 10
3
[LLVMdev] Question about SPARC target status
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
2008 Nov 12
2
[LLVMdev] Question about SPARC target status
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
2008 Nov 12
2
[LLVMdev] Question about SPARC target status
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
2008 Nov 11
0
[LLVMdev] Question about SPARC target status
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.
2008 Nov 11
2
[LLVMdev] Question about SPARC target status
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
2008 Nov 11
0
[LLVMdev] Question about SPARC target status
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,
2008 Nov 11
2
[LLVMdev] Question about SPARC target status
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
2008 Nov 12
0
[LLVMdev] Question about SPARC target status
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
2008 Nov 12
0
[LLVMdev] Question about SPARC target status
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
2008 Nov 11
0
[LLVMdev] Question about SPARC target status
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,
2008 Nov 11
0
[LLVMdev] Question about SPARC target status
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
2010 Mar 27
2
[LLVMdev] Static code generation - is it gone from LLVM 2.7?
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
2008 Nov 11
2
[LLVMdev] Question about SPARC target status
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
2010 Mar 27
2
[LLVMdev] Static code generation - is it gone from LLVM 2.7?
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
2010 Mar 27
0
[LLVMdev] Static code generation - is it gone from LLVM 2.7?
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
2010 Mar 27
2
[LLVMdev] Static code generation - is it gone from LLVM 2.7?
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
2008 Nov 11
4
[LLVMdev] Question about SPARC target status
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)