similar to: [LLVMdev] LLVM JIT Compilation Time vs Execution Time

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

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

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,

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:

*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

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>

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

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>

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

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

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 >>

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

Hi Xin, Thank you for your reply! I have tried the 3 alias analyses you have mentioned on LLVM 3.5: 1) $ opt -globalsmodref-aa -aa-eval < xxx.bc > /dev/null (May-alias response 100%) 2) $ opt -tbaa -aa-eval < xxx.bc > /dev/null (May-alias response 100%) 3) $ opt -cfl-aa -aa-eval < xxx.bc> /dev/null (Unknown command line argument '-cfl-aa') It seems that they are not

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

I think it is still be hosted on some bzr servers. Thanks Xin On Thu, Jan 5, 2012 at 12:20 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Is acovea still being distributed? The link that I was able to find > (http://www.coyotegulch.com/products/acovea/) is no longer valid. > >  -Hal > > On Thu, 2012-01-05 at 12:06 -0500, Xin Tong wrote: >> Has anyone tried acovea on

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

On 07/15/2015 07:05 PM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Xin Tong" <trent.xin.tong at gmail.com> >> To: "Philip Reames" <listmail at philipreames.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, llvmdev at cs.uiuc.edu >> Sent: Wednesday, July 15, 2015 6:35:11 PM >> Subject: Re: [LLVMdev] LICM

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

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

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