Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL"
2012 Oct 19
0
[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL
Personally, I'd love to see a setup where instead of LLVM implementing each
calling convention and ABI hack, we provide a means of actually describing
this. Specifically, I'd love to see a design for how to specify in the IR
which register(s) (if any register(s)) a particular value should be placed
into.
Don't get me wrong, I don't have any good ideas about how to do this, I'm
2012 Oct 19
2
[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL
On 19 October 2012 16:40, Chandler Carruth <chandlerc at google.com> wrote:
> Don't get me wrong, I don't have any good ideas about how to do this, I'm
> just hoping someone does. End result might allow something like:
>
> declare void @foo(double inreg <eax,edx> %x)
Hi Chandler,
We were discussing about this on the Cambridge LLVM Social a while
ago, and we
2012 Oct 20
0
[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL
Hi Rafael,
On 19/10/12 18:27, Rafael EspĂndola wrote:
>> Don't get me wrong, I don't have any good ideas about how to do this, I'm
>> just hoping someone does. End result might allow something like:
>>
>> declare void @foo(double inreg <eax,edx> %x)
>
> Not sure I would go all the way to specifying registers in the IL
> (although I liked it at
2012 Oct 20
2
[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL
On Oct 20, 2012, at 12:58 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Rafael,
>
> On 19/10/12 18:27, Rafael EspĂndola wrote:
>>> Don't get me wrong, I don't have any good ideas about how to do this, I'm
>>> just hoping someone does. End result might allow something like:
>>>
>>> declare void @foo(double inreg <eax,edx>
2012 Oct 19
2
[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL
> Don't get me wrong, I don't have any good ideas about how to do this, I'm
> just hoping someone does. End result might allow something like:
>
> declare void @foo(double inreg <eax,edx> %x)
Not sure I would go all the way to specifying registers in the IL
(although I liked it at some point). What I like most right now is
something along the lines of
2012 Oct 19
0
[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL
Hi Renato,
> On 19 October 2012 16:40, Chandler Carruth <chandlerc at google.com> wrote:
>> Don't get me wrong, I don't have any good ideas about how to do this, I'm
>> just hoping someone does. End result might allow something like:
>>
>> declare void @foo(double inreg <eax,edx> %x)
>
> Hi Chandler,
>
> We were discussing about this
2012 Oct 22
0
[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL
>>> Not sure I would go all the way to specifying registers in the IL
>>> (although I liked it at some point). What I like most right now is
>>> something along the lines of
>>> http://llvm.org/pr12193. That makes it explicit if something is on the
>>> stack or in registers and that information is correct for both the
>>> caller and callee.
2012 Oct 20
0
[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL
On Sat, Oct 20, 2012 at 10:37 AM, Renato Golin <rengolin at systemcall.org> wrote:
> On 19 October 2012 17:00, Duncan Sands <baldrick at free.fr> wrote:
>> That said, I also don't like the idea of filling the IR with tons of target
>> specific stuff.
>
> In this case, I think it's even worse than "aapcs" or "fastcall", that
> are
2012 Oct 20
4
[LLVMdev] How to represent __attribute__((fastcall)) functions in the IL
On 19 October 2012 17:00, Duncan Sands <baldrick at free.fr> wrote:
> That said, I also don't like the idea of filling the IR with tons of target
> specific stuff.
In this case, I think it's even worse than "aapcs" or "fastcall", that
are target dependent, but at a higher level.
Proposing at which register each variable will be, forces the
front-ends to
2007 Oct 05
0
[LLVMdev] RFC: Tail call optimization X86
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.
2007 Oct 05
5
[LLVMdev] RFC: Tail call optimization X86
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
2007 Oct 05
0
[LLVMdev] RFC: Tail call optimization X86
On Fri, 5 Oct 2007, Arnold Schwaighofer wrote:
>> to me like llvm-gcc honors that. Certainly it should.
>
> This would imply one fastcc abi (callee pops args on return) to rule
> them all?
> That is only if fastcall translates to llvm fastcc of course.
fastcall != fastcc. fastcall is a well defined convention on x86 that has
very specific ABI requirements. fastcc, on the
2019 Sep 20
2
About detailed rule of fastcall
Hello.
I'm trying to understand how fastcall works.
As far as I know, first two integer type arguments are passed in ecx and
edx.
I tested several test, but the result was different from what I expected
#1
typedef struct _data_t {
int d;
} data_t;
void __attribute__((fastcall)) test_suuu(data_t s, unsigned int a,
unsigned int b, unsigned int c);
unsigned int a is passed
2008 Sep 30
2
[LLVMdev] Possible bug in x86 code generation for fastcall on gnu/linux
Hi,
When compiling this function:
__attribute__((fastcall)) int f(int x, int y) {
return 0;
}
llvm 2.3 produces the following x86 assembler (with directives removed):
f:
xorl %eax, %eax
ret $4
Where as GCC (version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) produces:
f:
xorl %eax, %eax
ret
Note the difference in ret.
Functions calling a fastcall function in llvm adjust the stack by 4 to
2007 Dec 15
2
[LLVMdev] fix warning with newer g++ compilers
Ok, here is the patch again... I also included fixes for the bits
that originally gave my mailer fits...
Two votes for orange, so I went with orange...
Doing diffs in .:
--- ./lib/AsmParser/LLLexer.cpp.~1~ 2007-12-14 22:09:06.000000000 -0800
+++ ./lib/AsmParser/LLLexer.cpp 2007-12-15 13:02:47.000000000 -0800
@@ -54,7 +54,7 @@ static uint64_t HexIntToVal(const char *
Result +=
2013 Sep 06
1
[PATCH 2/2] com32/disk: Improve flow at disk_write_sectors and disk_read_sectors.
This patch will improve the flow at disk_write_sectors and disk_read_sectors significantly,
but it *will* introduce bugs if either of the above functions gets called before disk_get_params.
---
com32/include/syslinux/disk.h | 21 +++++
com32/lib/syslinux/disk.c | 170 +++++++++++++++++++++--------------------
2 files changed, 108 insertions(+), 83 deletions(-)
diff --git
2013 Sep 06
1
[PATCH 2/2 v2] com32/disk: Improve flow at disk_write_sectors and disk_read_sectors.
This patch will improve the flow at disk_write_sectors and disk_read_sectors.
It does that by creating a table of values respective to the operation.
Besides, read and write operations are pretty similar to each other,
so I redesigned the routines to avoid duplication.
Signed-off-by: Raphael S.Carvalho <raphael.scarv at gmail.com>
---
com32/include/syslinux/disk.h | 18 ++++
2003 Sep 15
2
Can not use read file SYSLINUX API call
Hi Peter Anvin
I tried to use open file and read file SYSLINUX API. But it always make my
PC104 freeze. My snip code :
================================================
int __start(void)
{
int ax,cx,dx,es,si,di,t;
com32sys_t inreg,outreg;
memset(&inreg, 0, sizeof inreg);
memset(&outreg, 0, sizeof outreg);
strcopy(__com32.cs_bounce, "test.txt");
inreg.eax.w[0] = 0x0006; //
2010 Apr 27
2
gpllib write_sectors() patch
Here is a partial patch that I'm using to illustrate a few questions
that I have.
Looking at the gpllib write_sectors (com32/gpllib/disk/write.c) it
looks like the allocated
size is wrong; size is in sectors so we should adjust the alloc/memcpy
by size*SECTOR.
Also, comparing core/diskio.c it looks like the registers aren't even
setup right.
In the patch below I put an #if 0 around the
2013 Sep 06
2
[PATCH 1/2] com32/lib/: Avoid unneeded allocation.
eparam will only be used if EBIOS is available on the underlying disk.
If not so, then there is no reason to allocate eparam.
---
com32/lib/syslinux/disk.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/com32/lib/syslinux/disk.c b/com32/lib/syslinux/disk.c
index 093751a..554bed3 100644
--- a/com32/lib/syslinux/disk.c
+++ b/com32/lib/syslinux/disk.c
@@ -73,7