similar to: [LLVMdev] MachineConstantPoolValue

Dale, > The user can specify the "fastcall" and "stdcall" attributes, and it > looks to me like llvm-gcc honors that. Certainly it should. fastcall and stdcall are specific calling conventions. They are not connected with fastcc at all. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

I tried the version you used, too. the resulting executable was still broken. I guess the reason is due to fastcall on function pointers, which Clang does not recognize. Consider the following snippet. #include <stdio.h> void __attribute__((fastcall)) f(int i) { printf("%d\n", i); } typedef void (*__attribute__((fastcall)) f_t)(int i); //typedef void

In the ARM backend, functions (and other 32 bit constants) are placed in a pool and loaded when needed. A problem with this is that ".weak" directives must be printed in the pool. This is not supported in the standard printer, so I think that I have found the first use for MachineConstantPoolValue :-) Creating the constant is easy, but I have two problems: 1) what are the methods

Hello > I don't know. I feel reluctant to generate different IRs for Win32 and > for Win64. Unfortunately, you should. Think about differences and between _Complex type and struct {double, double}. >From LLVM's point of view these are same types, however many ABIs have special rules for passing / returning _Complex, this is possible to handle in frontend only. > Since the C

On Wed, 6 Dec 2006, [UTF-8] Rafael Esp?ndola wrote: > In the ARM backend, functions (and other 32 bit constants) are placed > in a pool and loaded when needed. Has this approach been replaced with your later constant pool patch? -Chris > A problem with this is that ".weak" directives must be printed in the > pool. This is not supported in the standard printer, so I think

Thanks, Anton! I didn't know about exceptions like _Complex that you mentioned. The only way to support them is to place the burden of correct parameter passing on the front-end, I understand that now. So, today I created a new transformation pass that makes sure that LLVM IR, which works alright with the default Win32 calling conventions, also plays nice with Win64 code within the limited

Hello Anton Thu, 3 Aug 2006 12:38:54 +0400 you wrote: > I've updated it yesterday and rebuilt - llvm built fine. But when > building llvm-gcc4 (also updated yesterday from new /trunk > directory) it fails with the same error. You might easily get llvm-gcc4-mingw32 binaries from "prerelease" directory. Since stdcall, fastcall & dllimport stuff is unsupported right now,

Hello, Wolfgang. > * How can I define parts of the ABI that cover calling conventions? You should write some parts of codegen, which will translate specific CC'ed code to the target assembler. In general, you have to write 2 routines: 1. Lowering of formal arguments (when function call is performed, function should "see" supplied arguments with specific CC) 2. Lowering of call

The Wine development release 1.1.24 is now available. What's new in this release (see below for details): - Support for freedesktop file associations. - Support for exception handling on 64-bit. - Improved ARB shaders. - Fixes for the FBO mode. - Many listview improvements. - Various bug fixes. The source is available from the following locations:

I'm trying to understand the LLVM calling conventions. Coming from a Windows C++ background, I'm familiar with three calling conventions: cdecl, stdcall, and fastcall. It looks like cdecl corresponds to ccc in LLVM, but I'm not sure about the other two. Best Regards, Jon

On 5 Oct 2007, at 20:00, Dale Johannesen wrote: >>> I am not to sure on that. because that would make modules compiled >>> with the flag on incompatible with ones compiled without the flag >>> off >>> as stack behaviour would mismatch. >>> It would be no problem to make the behaviour dependent on the -tail- >>> call-opt flag. i am not sure

Hi All, Here's the first draft of the release announcement for LLVM 1.9 that I'm working on. I'm sure I've forgotten and overlooked something, if so, please let me know! ----- 8< ------ 8< ----- <notes> Note: LLVM now correctly builds itself and passes all regression tests on Darwin X86 and Darwin PPC. No one has tried other targets to my knowledge. We hit

On Wed, 20 Feb 2008, Raja Mukherji wrote: > Hi all, > I was wondering what the best way of adding a custom calling convention in llvm? It is quite easy to add custom calling conventions. Check out how the various x86 fastcall, stdcall, etc things are handled. > In particular, for the x86 platform, I want: > > on entry > > esi = size of argument block > edi = address of

When attempting to compile this simple testing tool http://github.com/oneclick/rubyinstaller/blob/fake/resources/tools/fakeruby.c I get the following: C:\Users\Jon\Documents\CDev\sandbox>llvm-gcc -Wall -o fakeruby.exe fakeruby.c Warning: resolving _GetModuleHandleA by linking to _GetModuleHandleA at 4 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable

On Oct 5, 2007, at 10:41 AM, Evan Cheng wrote: > > On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > >> Hi Evan, >> I incoporated the changes you request but to the following i have got >> a question: >> >>> Also, moving the option >>> there will allow us to change fastcc ABI (callee popping arguments) >>> only when this option is

Begin forwarded message: > From: Evan Cheng <evan.cheng at apple.com> > Date: 11 September 2007 19:26:39 GMT+02:00 > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] RFC: Tail call optimization X86 > Reply-To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > > Hi Arnold, > > Thanks for the patch. Some questions

On 20/02/2008, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 20 Feb 2008, Raja Mukherji wrote: > > Hi all, > > I was wondering what the best way of adding a custom calling convention in llvm? > > It is quite easy to add custom calling conventions. Check out how the > various x86 fastcall, stdcall, etc things are handled. Am I correct in thinking that it's

Hi Arnold, Thanks for the patch. Some questions and commons: 1. Have you test it against the llvm test suite? Does it work if fp elimination optimization is turned off? 2. Please follow llvm coding convention and make sure every line fits in 80 columns. 3. enum NameDecorationStyle { None, StdCall, - FastCall + FastCall, + FastCC // the normal fastcc calling convention }; Why is

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and

Dale, > I see. Could we please change its name then? fastcc? > The .ll file uses > x86_fastcallcc for fastcall, for an additional level of confusion. It was made intentionally to outline the target-specific nature of CC. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.