Hi Nat Tuck,

Thanks for working on profiling and optimizing the
kernel compiler!

The kernel lib linkage time probably went up after LLVM
decided to remove llvm-ld which actually had support for linking
archive bitcode libs which AFAIK used a similar indexing
optimization you now added. Now we use the llvm-link which does
the dumb linking of the whole kernel lib to the kernel after
which we remove the unneeded functions with global DCE before further
optimizations.

On 07/21/2013 06:31 PM, Nat Tuck wrote:
> Selecting which bitcode files to link in to user code probably could be done 
> as
> an LLVM pass - traverse the bitcode for extern declarations or call sites if 
> the
> declarations aren't easy to get at and then lookup those functions in
> "functions.index". It'd probably be faster too, even just because llvm-dis
> probably isn't a huge optimization target for the LLVM folks, but I don't 
> think
> it's the bottleneck at this point.

Yes, an LLVM Module pass or even just a C/C++ function that calls the
required LLVM APIs to do the job. The functions.index could be generated
to a C header file and compiled in the libpocl.so - even the overheads of
reading that index file would not be required then.

We are heading (with Kalle leading the way) towards making the kernel
compilation happen in a single process without spawning any new processes,
thus avoid executing any helper scripts. So, like Kalle wrote, the additional
perl script would go a bit backwards in that goal.

Thanks,
-- 
--Pekka


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
pocl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pocl-devel

Reply via email to