similar to: [LLVMdev] Header in bitcode format 3.0?

On 9 May 2011 20:56, Samuel Crow <samuraileumas at yahoo.com> wrote: > In the past I've worked on a PEG parser generator for any LLVM-based language to use.  One obstacle we ran into when generating LLVM IR assembly was that we'd end up cutting and pasting a list of declarations and aliases into every .ll file that needed to link with the others.  I'd propose that in the

On May 9, 2011, at 1:41 PM, Renato Golin wrote: [snip] > One example is the struct byval. The ARM back-end still doesn't > support struct byval (maybe now it does, I was away for a while), The ARM backend now supports struct byval for APCS. Extending it to support AAPCS shouldn't be too difficult. Alas, I won't have time to revisit this in the near future. stuart

On Wed, May 11, 2011 at 11:42 PM, Stuart Hastings <stuart at apple.com> wrote: > > On May 9, 2011, at 1:41 PM, Renato Golin wrote: > > [snip] > >> One example is the struct byval. The ARM back-end still doesn't >> support struct byval (maybe now it does, I was away for a while), > > The ARM backend now supports struct byval for APCS.  Extending it to

On May 12, 2011, at 12:30 AM, Sandeep Patel wrote: > On Wed, May 11, 2011 at 11:42 PM, Stuart Hastings <stuart at apple.com> wrote: >> >> On May 9, 2011, at 1:41 PM, Renato Golin wrote: >> >> [snip] >> >>> One example is the struct byval. The ARM back-end still doesn't >>> support struct byval (maybe now it does, I was away for a

On 12 May 2011 15:43, Stuart Hastings <stuart at apple.com> wrote: > I'm not familiar with AAPCS-VFP, but I'd assume that any byval struct should be passed by value, as if byval didn't exist. Not if the argument(s) fits into the specified registers. There's where the ABI comes in. In a nutshell, the AAPCS-VFP extends the AAPCS to include cases where the arguments are

Hi Sandeep, >> The ARM backend now supports struct byval for APCS. Extending it to support AAPCS shouldn't be too difficult. Alas, I won't have time to revisit this in the near future. > > It's slightly unclear to me what byval means for an ABI that passes > some structs in registers, such as AAPCS-VFP. I think in that case the front-end is supposed to extract the

>That seems an interesting concept, more or less like guarded headers  in C or import mechanisms in Java or Python. However, that goes a bit  off the track with regards to IR.  >The more semantics you add to IR, the more complex the middle-end  needs to be to deal with the idiosyncrasies and the less powerful is  the compiler. I for one always welcome changes in the IR regarding 

Hello Vitaly, Clang supports LLVM Bitcode formatted precompiled headers if that is what you are looking for. LLVM-GCC might be a different story though. Also note that these headers will be different from one operating system to the next. If you're looking for something portable, test out my wrapper at http://sourceforge.net/projects/llvmlibc/ in the SVN repo. --Sam ----- Original

Hello LLVM list, I'm working on a wrapper for LibC and I think it would work a whole lot better for what I'm trying to do if I wasn't forced to use a specific endianness. I'm trying to make it work in such a way that the compiler can generate code for a generic LLVM target such that the bitcodes won't need to have the alignment information or endianness until the final link

Am 19.06.2013 18:01, schrieb JF Bastien: > > From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program > because ABIs are different (e.g. PNaCl pointers are always 32-bit > even when running on x86_64 platform). > So PNaCl program can't access any data structures of the host >

On Tue, Jun 18, 2013 at 2:06 PM, Eli Bendersky <eliben at google.com> wrote: > > > > On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <silvas at purdue.edu> wrote: > >> Instead of a blacklist, why not a whitelist? Given the size of LangRef, >> you're bound to leave something out of your blacklist that needs to be >> there (also, future additions to

> From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program because > ABIs are different (e.g. PNaCl pointers are always 32-bit even when running > on x86_64 platform). > So PNaCl program can't access any data structures of the host program > directly. The only communication way is by using syscalls,

On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <silvas at purdue.edu> wrote: > Instead of a blacklist, why not a whitelist? Given the size of LangRef, > you're bound to leave something out of your blacklist that needs to be > there (also, future additions to LLVM IR will need to be added to the > blacklist; are you sure you can catch *all* of them?). A whitelist seems >

Hi, I would like to generate an LLVM bitcode file that contains all the types and functions declared in a header file. For example, the following code should make the llvm compiler put all type information contained in stdio.h in the resulting bitcode file. #include <stdio.h> int main() { return 0; } Unfortunately, when compiled with "llvm-gcc -g -emit-llvm -c test.c", the

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

Hello OvermindDL1, We are implementing an extensible language. That's one where you can add commands and constructs to the language without having to recompile the parser. We want compilation of the parser in order to "freeze" it but only as an option. One goal is to eventually get the macro functions of our language to the point where they are equivalent to the template

On 18 June 2013 15:08, Sean Silva <silvas at purdue.edu> wrote: > On Tue, Jun 18, 2013 at 2:06 PM, Eli Bendersky <eliben at google.com> wrote: > >> On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <silvas at purdue.edu> wrote: >> >>> Instead of a blacklist, why not a whitelist? Given the size of LangRef, >>> you're bound to leave something out

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

Hi Eli, Recently, I proposed some changes to LLVM to do more lowering of illegal types (like i128 or i17) and other things within the LLVM IR layer, and the proposal was roundly rejected by the LLVM community: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061567.html PNaCl is essentially doing what my proposal described. How do you expect to reconcile the community's desire to avoid

----- Original Message ---- > From: Eli Friedman <eli.friedman at gmail.com> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Monday, August 31, 2009 3:49:01 PM > Subject: Re: [LLVMdev] accessing a bitcode library exported from C++ using the JIT > > On Mon, Aug 31, 2009 at 12:17 PM, Samuel