llvm dev - Jun 2010 - [LLVMdev] Another two questions on LLVM

Hi all, 

Considering the limit time I have for an implementation, I better ask
for your inputs on a few questions. Any answer is to be much
appreciated.

First, how does LLVM handle the "new statement" of C++? Could any one
give me any hint?

Second, what properties does the callgraph generated by LLVM has? One
property I am interesting in is whether the callgraph is a safe
approximation of its corresponding run-time callgraph.

Third, does LLVM provide any strategy to resolve function calls? If
yes, what strategies does it employ?


Thanks!

Best,
Xiaolong

On Mon, Jun 7, 2010 at 12:03 PM, Xiaolong Tang <xiaolong.snake at
gmail.com> wrote:
> Hi all,
>
> Considering the limit time I have for an implementation, I better ask
> for your inputs on a few questions. Any answer is to be much
> appreciated.
>
> First, how does LLVM handle the "new statement" of C++? Could any
one
> give me any hint?
Try looking at the output of llvm-g++ or clang++.  Essentially, it
expands into a call to operator new and a call to the appropriate
constructor.
> Second, what properties does the callgraph generated by LLVM has? One
> property I am interesting in is whether the callgraph is a safe
> approximation of its corresponding run-time callgraph.
It's safe in the sense that it's conservatively correct.
> Third, does LLVM provide any strategy to resolve function calls? If
> yes, what strategies does it employ?
LLVM has general constant propagation, which also applies to function
pointers.  There aren't really any strategies specific to indirect
calls, besides minor tweaks like varying inlining thresholds.
Resolving C++ virtual function calls is a problem which isn't
completely solved yet; see http://llvm.org/bugs/show_bug.cgi?id=3100 .

-Eli

Xiaolong Tang wrote:
> First, how does LLVM handle the "new statement" of C++? Could any
one
> give me any hint?
>   
It doesn't. Handling C++'s new expression (not statement) is up to the
compiler frontend. Clang handles it by emitting a call to the
runtime-provided operator new function (which is probably implemented in
terms of malloc) followed by a constructor call, if
applicable.
> Third, does LLVM provide any strategy to resolve function calls? If
> yes, what strategies does it employ?
>   
What do you mean by resolve?

Sebastian

Hi Xiaolong,
> First, how does LLVM handle the "new statement" of C++? Could any
one
> give me any hint?
LLVM doesn't have special support for "new".  It's up to the
C++ front-ends
(clang++, llvm-g++, g++-4.5+dragonegg) to lower "new" to LLVM IR.  You
can
find out how by pasting C++ code into http://llvm.org/demo
For example, "int *n(void) { return new int; }" ->

define i32* @_Z1nv() {
entry:
   %0 = tail call i8* @_Znwm(i64 4)                ; <i8*> [#uses=1]
   %1 = bitcast i8* %0 to i32*                     ; <i32*> [#uses=1]
   ret i32* %1
}

declare i8* @_Znwm(i64)
> Second, what properties does the callgraph generated by LLVM has? One
> property I am interesting in is whether the callgraph is a safe
> approximation of its corresponding run-time callgraph.
It is, otherwise it would be useless.
> Third, does LLVM provide any strategy to resolve function calls? If
> yes, what strategies does it employ?
This is mostly done by the the inline and instcombine passes.

Ciao,

Duncan.

Hello Sebastian, 

Thanks!
> It doesn't. Handling C++'s new expression (not statement) is up to
the
> compiler frontend. Clang handles it by emitting a call to the
> runtime-provided operator new function (which is probably implemented in
> terms of malloc) followed by a constructor call, if applicable.
Just reminded me of the accurate C++ syntax grammar. The proper
description is new expressions rather than new statements.
> > Third, does LLVM provide any strategy to resolve function calls? If
> > yes, what strategies does it employ?
> >   
> What do you mean by resolve?
I mean to say the way to resolve virtual functions in C++. I am
currently experimenting to write an analysis pass in LLVM. One
prerequisite of the analysis is to have a safe approximation of a
program's run-time callgraph. Fortunately, Eli basically answered my
questions. 

Thanks all!

Best, 
Xiaolong