Displaying 5 results from an estimated 5 matches for "setheighttoatleas".
2012 Nov 07
2
[LLVMdev] Using LLVM to serialize object state -- and performance
.../dl.dropbox.com/u/46791180/callgraph.pdf
is a call graph generated by kcachegrind. I still don't understand all the numbers (and this PDF seems not to include commas where it should), but if you look at the left fork, the bottom two ovals, "Schedule..." is called 16K times and "setHeightToAtLeas..." is called 37K times. On the right fork, RAGreed... is called 35K times.
Those are far too many calls to *anything* for a simple sequence of "call" LLVM instructions. Something seems horribly wrong.
- Paul
2012 Nov 12
0
[LLVMdev] Using LLVM to serialize object state -- and performance
.../dl.dropbox.com/u/46791180/callgraph.pdf
is a call graph generated by kcachegrind. I still don't understand all the numbers (and this PDF seems not to include commas where it should), but if you look at the left fork, the bottom two ovals, "Schedule..." is called 16K times and "setHeightToAtLeas..." is called 37K times. On the right fork, RAGreed... is called 35K times.
Those are far too many calls to *anything* for a simple sequence of "call" LLVM instructions. Something seems horribly wrong.
- Paul
_______________________________________________
LLVM Developers maili...
2012 Nov 13
3
[LLVMdev] Using LLVM to serialize object state -- and performance
...x.com/u/46791180/callgraph.pdf
>
> is a call graph generated by kcachegrind. I still don't understand all the numbers (and this PDF seems not to include commas where it should), but if you look at the left fork, the bottom two ovals, "Schedule..." is called 16K times and "setHeightToAtLeas..." is called 37K times. On the right fork, RAGreed... is called 35K times.
>
> Those are far too many calls to *anything* for a simple sequence of "call" LLVM instructions. Something seems horribly wrong.
>
> - Paul
>
>
> __________________________________...
2012 Nov 06
0
[LLVMdev] Using LLVM to serialize object state -- and performance
Hi Paul,
I think you may have gone beyond what I understand in how the legacy JIT code works. It looks like the call to addGlobalMapping should short-circuit the named function look up that I described, but I can't account for why it behaves differently on Mac vs. Linux.
I still don't understand how the external pointers persist between writing and reading, but it sounds like you have
2012 Nov 06
3
[LLVMdev] Using LLVM to serialize object state -- and performance
Thanks for responding. Sorry for the delay in my reply, but I was dealing with hurricane Sandy. Anyway....
My software build produces libmylib.so. The JIT'd function only calls external C functions in libmylib.so and not other JIT'd functions. The C functions are simple thunks to call constructors. For example, given:
class BinaryNode : public Node {
public:
BinaryNode( Node