similar to: [LLVMdev] LLVM Benchmarks

Displaying 20 results from an estimated 30000 matches similar to: "[LLVMdev] LLVM Benchmarks"

2011 Mar 08
0
[LLVMdev] LLVM Static & Dynamic Compiler Benchmarks
I come from a Java JIT backgroud, I would like to know what are the typical benchmarks for the static llvm compiler and for the LLVM JIT performance? -- Kind Regards Xin Tong -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110307/42449da2/attachment.html>
2011 Apr 04
1
[LLVMdev] LLVMdev Digest, Vol 82, Issue 7
sounds like a good idea to me. but one of the current issues of back-patching in the LLVM is that the back-patching is not done atomically on some of the architectures, i.e. Intel x86. and this makes LLVM JIT not thread-safe in lazy compilation mode. what we need to make sure is that the "updating the resolution for a given symbol" you mentioned is done in an atomic fashion. also, how
2011 Apr 04
0
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
On 29 March 2011 12:35, Xin Tong Utoronto <x.tong at utoronto.ca> wrote: > *Project Description:* > > * > * > > LLVM has gained much popularity in the programming languages and compiler > industry from the time it is developed. Lots of researchers have used LLVM > as frameworks for their researches and many languages have been ported to > LLVM IR and interpreted,
2011 Feb 23
1
[LLVMdev] LLVM ExecutionEngine/JIT trampoline question
I understand that we need to push the address to a register then branch using the register. But i am asking why there is a trampoline there such that a call to foo is first branched to an snippet and the snippet branches to the X86CompilationCallback. is this snippet necessary ? Thanks Xin On Tue, Feb 22, 2011 at 12:39 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > The
2011 Feb 22
0
[LLVMdev] LLVM ExecutionEngine/JIT trampoline question
The address of the callee may be more than 2 GB away in memory, which cannot be encoded as an immediate offset in the call instruction. So, the value is first materialized with a mov instruction which can encode the immediate and then jumped to through a register. Reid On Tue, Feb 22, 2011 at 12:03 PM, Xin Tong Utoronto <x.tong at utoronto.ca> wrote: > I have a question on the LLVM JIT
2011 Mar 29
5
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
*Project Description:* * * LLVM has gained much popularity in the programming languages and compiler industry from the time it is developed. Lots of researchers have used LLVM as frameworks for their researches and many languages have been ported to LLVM IR and interpreted, Just-in-Time compiled or statically compiled to native code. One of the current drawbacks of the LLVM JIT is the lack of an
2011 Feb 22
2
[LLVMdev] LLVM ExecutionEngine/JIT trampoline question
I have a question on the LLVM JIT I did some brief memory reading one day and I found that a call to a non-library function is resolved by the X86CompilationCallback, but the X86CompilationCallback is reached through a trampoline. why can not the generated code jump to the X86CompilationCallback function directly ? 0x2b0a6a4d103b: mov $0x2b0a6a561010,%rax 0x2b0a6a4d1045:
2011 Feb 28
1
[LLVMdev] LLVM JIT Compilation Time vs Execution Time
Do any of you have an idea as to what the Compilation Time vs Execution Time looks like in LLVM JIT with most aggressive optimizations on. Is adaptive compilation going to bring any benefits to the LLVM JIT ? -- Kind Regards Xin Tong -------------- next part -------------- An HTML attachment was scrubbed... URL:
2011 Apr 01
2
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
On Thu, Mar 31, 2011 at 6:47 PM, Eric Christopher <echristo at apple.com>wrote: > > > >> So, one way that current projects use the JIT is via > getPointerToFunction() which returns an address that can then be casted and > called with the appropriate arguments. The compile task itself is often done > on a separate thread. How would you deal with the updating problem
2011 Mar 31
2
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
On Tue, Mar 29, 2011 at 4:45 PM, Eric Christopher <echristo at apple.com>wrote: > > > > Project Outline: > > > > > > > > Currently, the LLVM JIT serves as a management layer for the executed > LLVM IR, it manages the compiled code and calls the LLVM code generator to > do the real work. There are levels of optimizations for the LLVM code >
2011 Mar 29
0
[LLVMdev] GSOC proposal submission
On Mon, Mar 28, 2011 at 6:58 PM, Xin Tong Utoronto <x.tong at utoronto.ca>wrote: > How do I submit my GSOC proposal to the llvmdev mailing list ? > Posting your proposal to the mailing list is just to get feedback *before* submitting it (which is very much recommended). To actually submit your proposal, you need to register on the Google Summer of Code website and submit it there.
2011 Apr 03
2
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
On Fri, Apr 1, 2011 at 1:26 PM, Eric Christopher <echristo at apple.com> wrote: > > On Apr 1, 2011, at 9:38 AM, Reid Kleckner wrote: > > > On Thu, Mar 31, 2011 at 11:15 PM, Eric Christopher <echristo at apple.com> > wrote: > >>> > >>> > >>> Then we would always have the location of the br B instruction in A, as > it is pushed
2011 Jun 24
0
[LLVMdev] LLVM autovectorization support
On 24 June 2011 21:13, Xin Tong Utoronto <x.tong at utoronto.ca> wrote: > I would like to know the status of the autovectorization support in LLVM. >  does LLVM have a loop dependence analysis, does LLVM have a infrastructure > for autovectorization ? etc. Not yet, but it's getting there... http://polly.grosser.es/ cheers, --renato
2011 Jun 24
2
[LLVMdev] LLVM autovectorization support
I would like to know the status of the autovectorization support in LLVM. does LLVM have a loop dependence analysis, does LLVM have a infrastructure for autovectorization ? etc. Kind Regards Xin Tong -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110624/3dc35318/attachment.html>
2012 Feb 07
0
[LLVMdev] clang errors on void main()
On Mon, Feb 6, 2012 at 6:51 PM, Xin Tong <xerox.time.tech at gmail.com> wrote: > Is there any way to stop this ? > > /home/socrates/llvm/llvm-3.0.src/benchmarks/powerstone/crc/crc.c:67:1: > error: 'main' must return 'int' > void main() > ^ > 1 error generated. You mean besides fixing the source of your benchmark so it's valid C? Not at the moment...
2012 Feb 08
1
[LLVMdev] clang errors on void main()
07.02.2012 07:27, Eli Friedman пишет: > On Mon, Feb 6, 2012 at 6:51 PM, Xin Tong<xerox.time.tech at gmail.com> wrote: >> Is there any way to stop this ? >> >> /home/socrates/llvm/llvm-3.0.src/benchmarks/powerstone/crc/crc.c:67:1: >> error: 'main' must return 'int' >> void main() >> ^ >> 1 error generated. > You mean besides
2011 Mar 28
3
[LLVMdev] GSOC proposal submission
How do I submit my GSOC proposal to the llvmdev mailing list ? -- Kind Regards Xin Tong -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110328/4f068139/attachment.html>
2012 Mar 15
0
[LLVMdev] GPU thread/block/grid size contraints in LLVM PTX backend
I don't think so, but you should check source code. On Tue, Mar 13, 2012 at 9:58 PM, Xin Tong <xerox.time.tech at gmail.com> wrote: > but does it have default values ? > > Thanks > > Xin > > On Tue, Mar 13, 2012 at 5:19 AM, Che-Liang Chiou <clchiou at gmail.com> wrote: >> You specify shader model, bit size and etc. arch-specified parameters >>
2012 Feb 12
0
[LLVMdev] llvm interprocedural analysis and optimization
There is/are implicit dependency for the optimization on its analysis. So, if you run the optimization, the analysis will be turned on implicitly, through the PassManager. Chuck On 2/12/2012 10:10 AM, Xin Tong wrote: > If I turn on one of the llvm interprocedural optimizations without > turning on the analysis it uses. will the analysis be turned on > automatically ? > > Thanks
2011 Apr 03
0
[LLVMdev] GSOC Adaptive Compilation Framework for LLVM JIT Compiler
On Apr 3, 2011, at 12:01 PM, Xin Tong Utoronto wrote: > Another way to do the patching is to first atomically inserted a self-loop jump -2 atomically (jump -2 takes 2 bytes and 2 bytes writing is atomic on x86 ) into the old branch address on x86 such that it stops all threads reaching this point. copy in the new compiled function address. and then re-patch the jump -2 with the correct