similar to: [LLVMdev] About clock and wait instruction

On Fri, 19 Dec 2003, Yueqiang wrote: > hi, > > like in C/C++ language there are time/date and istream::sync function. If an operation can be written in C/C++ or some other high-level language, then it should be. It can be directly compiled to LLVM bytecode. In our case you can llvm-dis llvm-gcc/lib/libstdc++.so to see what we compile it into. > also in RISC system Data/Inst Cache

On Sun, Jul 3, 2011 at 9:07 AM, Chris Lattner <clattner at apple.com> wrote: > Hi Talin, > > Interesting post, > > On Jul 1, 2011, at 11:05 AM, Talin wrote: > > *Garbage collection is still way too difficult*. The biggest problem is > the inability to track SSA values - it requires the > > > *Light-weight coroutines* would be a "nice to have", as

On Tue, Jul 5, 2011 at 11:35 AM, Talin <viridia at gmail.com> wrote: > On Sun, Jul 3, 2011 at 9:07 AM, Chris Lattner <clattner at apple.com> wrote: > >> Hi Talin, >> >> Interesting post, >> >> On Jul 1, 2011, at 11:05 AM, Talin wrote: >> >> *Garbage collection is still way too difficult*. The biggest problem is >> the inability to

On 9/19/13 9:53 AM, Herbei Dacian wrote: > > Hi Konstantin, > good point. > but I my intention is to have something like the llva project. If you want something like the LLVA project for user-space applications, then you basically want to use LLVM as-is. The only things missing are the instructions that replace certain in-line assembly sequences that cannot be represented by

Hi Talin, Interesting post, On Jul 1, 2011, at 11:05 AM, Talin wrote: > Garbage collection is still way too difficult. The biggest problem is the inability to track SSA values - it requires the > Light-weight coroutines would be a "nice to have", as would better concurrency primitives. These are things I could Tackling the "still way too difficult" and "should

Estimado Manuel Spíndola Del repositorio r descargo el paquete, me refiero a: Package source: vcd_1.2-13.tar.gz Descomprimo y busco el archivo que creo conveniente, en este caso copio y pego el código de mosaicplot A partir de ahí el trabajo es interpretar el código, copiar la parte útil, modificar lo conveniente, en fin, lleva tiempo pero se aprende mucho de esa forma, yo lo realice con

Muchas gracias Eva. Manuel 2013/7/5 Eva Prieto Castro <evapcastro@yahoo.es> > Hola, Manuel: > > Si descomprimes el tar.gz indicado por Marcuzzi, y accedes a la subcarpeta > R, en el archivo legends.R buscas la cadena p-value, y en el archivo > strucplot.R es donde creo que modificas el "Pearson residuals" (busca por > "Pearson\nresiduals"). > >

Muchas gracias Javier, Lo que yo quiero es cambiar el título de la leyenda que dice "Pearson residuals" a español "Residuales de Pearson", pero no me doy cuenta como. También en lugar de "p-value", que diga "Valor de P". Es posible? Manuel 2013/7/4 Marcuzzi, Javier Rubén <javier.ruben.marcuzzi@gmail.com> > Estimado Manuel Spíndola > >

On Fri, 19 Dec 2003, Yueqiang wrote: > In high level languge there are usually have time and sync instruction, > to handle async and sync operation. > I want to know how LLVM take an count of these. I'm not sure exactly what 'time' and 'sync' operations you're talking about, or what languages support them. However, LLVM is designed to make it trivial to

On Tue, 10 Jul 2007, Scott Michel wrote: >> The idea is to review the atomic_ops model, and if it makes sense, just >> reuse it. (e.g., atomic_ops seems to have (basic?) support for Alpha). > > atomic_ops may have interesting ideas on how Chandler might proceed and > implement, but using its code is very unlikely. I think that Torvald's point here is that the

The vector LLVA extension will not be merged into the 1.6 release branch? It will make me have to merge twice: one for 1.6 and one for vector LLVA. When do you plan to merge the vector LLVA to the main trunk, please? On 26/10/05, Chris Lattner <sabre at nondot.org> wrote: > > Hi All, > > I'm putting together the announcement for the LLVM 1.6 release. Here is > what I

Hello icecast-dev, this patch against the current ices module CVS tree fixes the following: PROBLEM: use of #include "thread.h" in (of all things) im_sun.[ch] can cause a compile error. REPRODUCTION: Compile source tree on Solaris 2.8 using gcc3.2.3 (SMCgcc) from sunfreeware.com will fail with a name space collision, eg: thread/thread.h:66: conflicting types for

Chris Lattner wrote: > On Fri, 19 Dec 2003, Yueqiang wrote: > > >>In high level languge there are usually have time and sync instruction, >>to handle async and sync operation. >>I want to know how LLVM take an count of these. > > > I'm not sure exactly what 'time' and 'sync' operations you're talking > about, or what languages

Is the source code for llva available esp the linux kernel port. Is there a project page for llva ? Mike On 2/3/06, John Criswell <criswell at cs.uiuc.edu> wrote: > Misha Brukman wrote: > > I don't know the current status of the LLVA project, so I will let the > > current developers chime in. Please send all LLVM and LLVA questions to > > llvmdev at cs.uiuc.edu .

Misha Brukman wrote: > I don't know the current status of the LLVA project, so I will let the > current developers chime in. Please send all LLVM and LLVA questions to > llvmdev at cs.uiuc.edu . My apologies for the late reply. > > ----- Forwarded message from N O S P A M <ti_dak at yahoo.com> ----- > > Date: Tue, 17 Jan 2006 09:47:32 -0800 (PST) > From: N O

On 4/2/07, Fabian Scheler <fabian.scheler at gmail.com> wrote: > Hello everybody, > > I'm curious whether there have been any attempts to perform > performance analysis on the LLVA level. I am interested in the > derivation of flow-facts (loop bounds etc. - what about the > value-range-propagation pass I read about on this list some time ago) > but even more I am

On Apr 3, 2007, at 10:55 AM, Andrew Lenharth wrote: > On 4/2/07, Fabian Scheler <fabian.scheler at gmail.com> wrote: >> Hello everybody, >> >> I'm curious whether there have been any attempts to perform >> performance analysis on the LLVA level. I am interested in the >> derivation of flow-facts (loop bounds etc. - what about the >>

Chris Lattner wrote: > On Fri, 18 May 2007, Keith Whitwell wrote: >> I'm interested in understanding the extent of the assumptions which llvm >> makes about the types of hardware it is capable of targeting. > > Different pieces of the compiler make different assumptions. In > particular, the code generator we ship is good for targetting certain > classes of

On Sat, 19 May 2007, Keith Whitwell wrote: >>> It seems that LLVA and by extension Vector-LLVA assumes that looping and >>> branching control flow can be expressed in terms of a simple "br" branch >>> operation. >> >> LLVA is not a part of LLVM, so I won't answer for it. > > OK, I guess I misunderstood the papers I pulled down - my

hi, In high level languge there are usually have time and sync instruction, to handle async and sync operation. I want to know how LLVM take an count of these. thanks yueqiang 2003/12/19 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031218/07381085/attachment.html>