svn commit: r223705 - projects/llvm-ia64/lib/clang/libllvmjit

[Roman Divacky]

> The following open items are on my mind:
> 
> 1.  On ia64, function prologues allocate a register frame that has
>     enough (stacked) registers for local scratch registers and 
>     outgoing function arguments. This means that I need to know
>     (after register allocation) how many (unique) scratch registers
>     are in use and what the largest number of arguments that need
>     to be passed in registers to children (the max being 8). Without
>     this information the compiler is forced to allocate the maximum
>     size (which is 96 stacked registers, of which 8 are outgoing).
>     This obviously eats into the register stack and probably causes
>     runtime failures on deep call chains.
 
I recommend you to do this little experiment (on amd64 or so):

pes ~$ cat test.c
void foo(int i) {
  printf("foo %i\n", i);
}

int main(int agc, char **argv)
{
  printf("hello world\n");
  for (unsigned i = 0; i < 5; ++i)
    foo(i);

}
pes ~$ clang -emit-llvm -c test.c                                                                                                                 test.c:2:3: warning: implicitly declaring C library function 'printf' with type 'int (const char *, ...)'
  printf("foo %i\n", i);
  ^
test.c:2:3: note: please include the header <stdio.h> or explicitly provide a declaration for 'printf'
1 warning generated.
pes ~$ llc -debug test.o

the llc -debug will show you a lot of interesting information on how llvm handles this code.
Among others you'll find there:

# Machine code for function foo:
Frame Objects:
  fi#0: size=4, align=4, at location [SP+8]
Function Live Ins: %EDI in %vreg0

I believe this is what you asked.


> 2.  [C++] vtable entries are not function pointers like on other
>     architectures. They are function descriptors. I think Nathan
>     said that PowerPC64 also have function descriptors. Anyway,
>     Duraid Madina (the author of the original ia64 backend) said
>     that support for this was missing from LLVM. I don't know if
>     this has changed in the mean time or whether I need to go
>     down into the bowels of LLVM and add support for this.

I would forget about C++ for now.

roman