similar to: [LLVMdev] Thinking about "whacky" backends

Sorry, forgot to CC the list. ----- Forwarded Message ----- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Joachim Durchholz <jo at durchholz.org> > Cc: > Sent: Tuesday, May 31, 2011 9:35 PM > Subject: Re: [LLVMdev] Thinking about "whacky" backends > > Hello, > > > ----- Original Message ----- >> From: Joachim Durchholz

Am 01.06.2011 23:25, schrieb Nate Fries: > That said, it seems like it ought to be possible to do the same thing > by emitting bitcode for all supported platform/arch combinations Wait... is bitcode not platform-agnostic? I thought it is. > and > compressing them in an archive, then decompressing and either > interpreting or JIT-compiling the appropriate bitcode for the >

What benefit do you get from having a backend here rather than an interpreter for LLVM IR? Cameron On May 31, 2011, at 5:30 PM, Joachim Durchholz wrote: > I've been tossing around some ideas about high-level backends. > > Say, have LLVM emit Perl code. > > Sounds whacky but isn't. It's good for the first bootstrapping phase in > environments where you don't

On May 31, 2011, at 7:36 PM, Samuel Crow wrote: <snip> >> >> Now my idea for a whacky backend: Just a wrapper of the bitcode writer with its >> own special target triple: bitcode-tarrget-neutral and a generic data layout >> that aligns to single bytes as a placeholder only. It should disallow >> overriding the alignment of individual instructions to avoid

Am 01.06.2011 04:57, schrieb Cameron Zwarich: > What benefit do you get from having a backend here rather than an interpreter for LLVM IR? A backend that's self-sufficient and covers the entire Unixoid world. That cuts down on the number of binaries that one needs to provide for autoinstallers and such. Generated Perl could be used to bootstrap an LLVM IR interpreter, for example.

-------- Original Message -------- Subject: Re: [LLVMdev] Thinking about "whacky" backends Date: Fri, 03 Jun 2011 14:44:05 -0400 From: Nate Fries <nfries88 at yahoo.com> To: Joachim Durchholz <jo at durchholz.org> On 6/3/2011 1:38 PM, Joachim Durchholz wrote: > Am 01.06.2011 23:25, schrieb Nate Fries: >> That said, it seems like it ought to be possible to do

Cameron Zwarich wrote: > What benefit do you get from having a backend here rather than an interpreter for LLVM IR? The same thing as an interpreter, just a native build (no need for an interpreter program, better speed, etc). This would be beneficial anywhere that "build once, deploy anywhere" functionality is desired, without resorting to using a higher-level language like C# or

On Wed, Jun 1, 2011 at 12:53 PM, Henry Mason <thefridgeowl at gmail.com> wrote: > This is pretty much what's happening with Portable Native Client, right? > > http://www.chromium.org/nativeclient/pnacl > > See also the first presentation from the November LLVM meeting: http://llvm.org/devmtg/2010-11/ PNaCl fixes data layout to be just "portable enough" to cover

On 5 October 2011 18:03, Justin Holewinski <justin.holewinski at gmail.com> wrote: >  So why must LLVM try to meet *both* goals?  Instead, different types of > front-ends can use custom intermediate representations that meet their > needs, and then lower to platform-specific LLVM IR before final code > emission.  I'm afraid that if LLVM gets into the game of trying to be the

Samuel Crow <samuraileumas at yahoo.com> writes: > Here's some of what it would take to make portable bitcodes in C or LLVM Assembly: A look at the work done on ANDF in the 90's may be helpful. I've only skimmed it but there's been some deep thinking about stuff like this. -Dave

On 6/3/2011 3:19 PM, Samuel Crow wrote: > Why not runtime checks? The constant folding and dead-code elimination passes would get rid of any redundant code in a later stage of compilation anyway. The important part, as I see it, is that LLVM already does constant folding and dead-code elimination. Meta-data might require more effort in the long run. > > --snip-- Less flexible for the

Now that the dust begins to settle... I'm wondering whether LLVM is for me. I'm working on something that can be used to create software for different environments: C/C++, JVM, CLR, Parrot, etc. I.e. one language for different environments, but not write once, run anywhere. Now what would be the role of LLVM in such an infrastructure? Just backend for C/C++ linkage, and I should go and

----- Original Message ----- > From: Nate Fries <nfries88 at yahoo.com> > To: Samuel Crow <samuraileumas at yahoo.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Cc: > Sent: Friday, June 3, 2011 6:52 PM > Subject: Re: [LLVMdev] Thinking about "whacky" backends > > Most JVMs perform terribly. Even Sun's has had notable performance

On 6/3/2011 3:19 PM, Joachim Durchholz wrote: >>>> compressing them in an archive, then decompressing and either >>>> interpreting or JIT-compiling the appropriate bitcode for the >>>> platform. This would just be a more flexible means to that same end. >>> Not sure how that is more flexible - care to elaborate? >> More flexible to the programmer,

On 6/2/2011 10:13 AM, Samuel Crow wrote: > Hi Nate, > > I've successfully ported one bitcode from Linux to Mac to Windows. All were x86 and the program was text-based, but I'd say my LLVM Wrapper would be worth some effort in the future if I could just get some help. Currently it just wraps StdIO.h with its own functions Naturally that would work perfectly fine on a similar

Hi Nate, I've successfully ported one bitcode from Linux to Mac to Windows.  All were x86 and the program was text-based, but I'd say my LLVM Wrapper would be worth some effort in the future if I could just get some help.  Currently it just wraps StdIO.h with its own functions. Here's some of what it would take to make portable bitcodes in C or LLVM Assembly: * Convert all

On Mar 30, 2008, at 12:39 PM, Joachim Durchholz wrote: > > Am Sonntag, den 30.03.2008, 10:28 -0700 schrieb Tanya Lattner: >> On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: >>> Look at how $LLVM_CONFIGURE is built, the final value is >>> >>> --prefix=/home/jo --enable-optimized --build=i686-pc-linux-gnu >>> --host=i686-pc-linux-gnu

On Mar 30, 2008, at 11:22 PM, Joachim Durchholz wrote: > > Am Sonntag, den 30.03.2008, 15:45 -0700 schrieb Tanya Lattner: >> On Mar 30, 2008, at 12:39 PM, Joachim Durchholz wrote: >> >>> >>> Am Sonntag, den 30.03.2008, 10:28 -0700 schrieb Tanya Lattner: >>>> On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: >>>>> Look at how

Hi all, I'm wondering what the comparative status of llvm-gcc4.0 vs. llvm-gcc4.2 is. Can anybody tell? (A URL would be fine, I may have been just too dumb to find it.) Regards, Jo

Am Sonntag, den 30.03.2008, 15:45 -0700 schrieb Tanya Lattner: > On Mar 30, 2008, at 12:39 PM, Joachim Durchholz wrote: > > > > > Am Sonntag, den 30.03.2008, 10:28 -0700 schrieb Tanya Lattner: > >> On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: > >>> Look at how $LLVM_CONFIGURE is built, the final value is > >>> > >>>