similar to: [LLVMdev] LLVM Static & Dynamic Compiler Benchmarks

Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] LLVM Static & Dynamic Compiler Benchmarks"

2011 Mar 08
0
[LLVMdev] LLVM Benchmarks
I come from a Java JIT backgroud, I am wondering what kind of benchmarks we use for the LLVM static compiler and JIT ? -- Kind Regards Xin Tong -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110307/be8efe7b/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 >>
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
2012 Mar 13
2
[LLVMdev] GPU thread/block/grid size contraints in LLVM PTX backend
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 > though -march, -mattr and -mcpu, but AFAIK, PTX backend does not use > the GPU thread/block/grid size information in optimization yet. > > On Mon, Mar 12, 2012 at 8:17 PM, Xin
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
2012 Jul 19
0
[LLVMdev] Bind a LLVM variable to a CPU register
On Thu, Jul 19, 2012 at 2:28 PM, John Criswell <criswell at illinois.edu> wrote: > On 7/19/12 1:23 PM, Jim Grosbach wrote: >> >> Not really, no. > > > If you really, really, wanted to do it, you could: > > 1) Hack the code generator to not use that register. It might be as simple > as modifying the TableGen file to not know that the register exists. In fact
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
2012 Mar 13
0
[LLVMdev] GPU thread/block/grid size contraints in LLVM PTX backend
You specify shader model, bit size and etc. arch-specified parameters though -march, -mattr and -mcpu, but AFAIK, PTX backend does not use the GPU thread/block/grid size information in optimization yet. On Mon, Mar 12, 2012 at 8:17 PM, Xin Tong <xerox.time.tech at gmail.com> wrote: > I am wondering that how does the LLVM PTX backend find out the > constraints on executing GPU
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,
2012 Jan 05
0
[LLVMdev] clang for opencl
On Thu, Jan 5, 2012 at 11:39 PM, Xin Tong <xerox.time.tech at gmail.com> wrote: > I do not know too much about clang, is opencl publicly supported in > clang ? how about cuda ? Anton at ARM commited theOpenCL patches, already. NVIDIA did not commit the CUDA patches, yet. > > Thanks > > Xin > _______________________________________________ > LLVM Developers mailing
2012 Jan 05
2
[LLVMdev] clang for opencl
> NVIDIA did not commit the CUDA patches, yet. But plans to? 2012/1/5 Liu <proljc at gmail.com>: > On Thu, Jan 5, 2012 at 11:39 PM, Xin Tong <xerox.time.tech at gmail.com> wrote: >> I do not know too much about clang, is opencl publicly supported in >> clang ? how about cuda ? > > Anton at ARM commited theOpenCL patches, already. > > NVIDIA did not
2012 Feb 28
1
[LLVMdev] LLVM Toronto social
can we get a confirmation on who is coming tomorrow ? Thanks Xin 2012/2/24 Andrew Clinton <andrew at sidefx.com>: > It would be fun to meet some other LLVM developers in TO, 7:00 on wed at > beer bistro should work for me. > > Andrew > > > On 02/24/2012 05:22 PM, Rafael Espíndola wrote: >> >> 2012/2/24 Xin Tong<xerox.time.tech at gmail.com>:
2012 Jul 19
0
[LLVMdev] Bind a LLVM variable to a CPU register
Not really, no. On Jul 19, 2012, at 11:14 AM, Xin Tong <xerox.time.tech at gmail.com> wrote: > I have a constant parameter in a LLVM function. Is there a way to > reserve a CPU register such that it also holds the value of the > parameter in LLVM x86 codegen ? > > Thanks > > Xin > _______________________________________________ > LLVM Developers mailing list
2012 Feb 24
2
[LLVMdev] LLVM Toronto social
2012/2/24 Xin Tong <xerox.time.tech at gmail.com>: > Hopefully you mean sometime in the evening on 29th. If this is the > case, count me in. Good point, I forgot to select a time :-) What about 19:00? > Thanks Cheers, Rafael
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
2012 Jul 19
5
[LLVMdev] Bind a LLVM variable to a CPU register
On 7/19/12 1:23 PM, Jim Grosbach wrote: > Not really, no. If you really, really, wanted to do it, you could: 1) Hack the code generator to not use that register. It might be as simple as modifying the TableGen file to not know that the register exists. 2) Use inline asm to put the constant into that register and fetch it from that register. The real question is: what larger goal are you
2012 Feb 24
0
[LLVMdev] LLVM Toronto social
It would be fun to meet some other LLVM developers in TO, 7:00 on wed at beer bistro should work for me. Andrew On 02/24/2012 05:22 PM, Rafael Espíndola wrote: > 2012/2/24 Xin Tong<xerox.time.tech at gmail.com>: >> Hopefully you mean sometime in the evening on 29th. If this is the >> case, count me in. > Good point, I forgot to select a time :-) > What about 19:00?
2012 Jul 19
0
[LLVMdev] Bind a LLVM variable to a CPU register
On Thu, Jul 19, 2012 at 2:28 PM, John Criswell <criswell at illinois.edu> wrote: > On 7/19/12 1:23 PM, Jim Grosbach wrote: >> >> Not really, no. > > > If you really, really, wanted to do it, you could: > > 1) Hack the code generator to not use that register. It might be as simple > as modifying the TableGen file to not know that the register exists. > 2)
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