search for: shugalev

Chris Lattner wrote: > On Mar 27, 2010, at 11:56 AM, Peter Shugalev wrote: > >>>> What exactly is expected to be coming? Will it be the same way MachO is >>>> currently implemented but with some flexibility to supply my own class >>>> to do actual object output? Or just a return of old ObjectCodeEmitter? >>> We'r...

On Thu, Jul 30, 2009 at 5:32 PM, Peter Shugalev<peter at shugalev.com> wrote: > Hello! > > I've just tried generating Win64 code and the result is not that good. > > First of all, XMM registers are saved without reason to do so. Not only > this slows the performance but leads to random crashes too. XMMs are > store...

...cond arguments goes to the stack at address RSP+10h and overwrites 'i' variable always resetting it to zero. Is anyone aware of the second bug? If I have some time I'll try to fix it by myself but it'd be much better if someone hints me where to start from. -- Best Regards Peter Shugalev

On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >>> >>> New method of emitting object code is ok for me. But it is still >>> experimental, isn't it? >> >> Yes. > > Thank you for answers! > > Now there is a way to implement what I'd like to. But it would be MUCH > better if...

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

Chris Lattner wrote: > On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: > >>>> New method of emitting object code is ok for me. But it is still >>>> experimental, isn't it? >>> Yes. >> Thank you for answers! >> >> Now there is a way to implement what I'd like to. But it would be MUCH >> better...

On 30-Jul-09, at 8:54 PM, Eli Friedman wrote: > On Thu, Jul 30, 2009 at 5:32 PM, Peter Shugalev<peter at shugalev.com> > wrote: >> Though the most problematic stuff is the lack of 'shadow zone' >> support >> in Win64 ABI. Or maybe I haven't figured out how to turn this on. In >> Win64 any function can treat 32 bytes of stack (RSP+08h..RSP+28h j...

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

...code emitter interface but at least it worked for me. 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? -- Best Regards Peter Shugalev

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, ju...

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

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

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? >> >> N...

...an 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? -- Best Regards Peter Shugalev

On Mar 27, 2010, at 1:50 PM, Peter Shugalev wrote: > Chris Lattner wrote: >> On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >> >>>>> New method of emitting object code is ok for me. But it is still >>>>> experimental, isn't it? >>>> Yes. >>> Thank you for answers! &...

On Mar 27, 2010, at 11:56 AM, Peter Shugalev wrote: >>> What exactly is expected to be coming? Will it be the same way MachO is >>> currently implemented but with some flexibility to supply my own class >>> to do actual object output? Or just a return of old ObjectCodeEmitter? >> >> We're integrati...

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

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

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)

...ncommited) advances in these areas? The most needed feature for me is sparc64 support. If I decide to implement these ones by myself what are the problems/guidelines/whatever? Why hasn't this been done before? I mean is it some technical problem or just lack of time? -- Best Regards Peter Shugalev