similar to: [LLVMdev] Rolling my own LLVM assembly language parser

jstanier wrote: > Hi everyone, > > I'm currently in the first year of my PhD, and I'm going to be looking at an > experimental IR for my thesis. After looking at a variety of research > compilers I've come to the conclusion that LLVM is the nicest to work with > for my purposes. I was considering writing the code to construct this > experimental IR from LLVM

Thank you both for your answers. The only reason I was interested in not using the built-in parsing library was that it would give me more flexibility over the language I program in, but if it means brushing up on my C++ then this isn't too much of a problem either. With regards to using the in-memory LLVM, that's also a good approach. However, I was thinking of structuring my thesis

Hello, > I was thinking of generating my own lexer and parser for LLVM assembly. I'm > aware that between the specification here: Why do you need this? There is already a parser library inside LLVM framework and you can use it directly without any problems. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Wednesday 25 March 2009 17:12:34 John Criswell wrote: > jstanier wrote: > > Hi everyone, > > > > I'm currently in the first year of my PhD, and I'm going to be looking at > > an experimental IR for my thesis. After looking at a variety of research > > compilers I've come to the conclusion that LLVM is the nicest to work > > with for my

You can achieve the 'standalone tools' effect using LLVM bitcode, which is a binary IR format. Then you can have: source code -> [llvm-gcc frontend] -> bc bc -> [your tool using llvm bitcode reader writer library, doing whatever mutations to the IR you want and spitting out bc again] -> bc bc -> [llvm backend (llc)/llvm-as/...] -> native code. Doesn't that meet your

On Wednesday 25 March 2009 14:16:42 Jon Harrop wrote: > I assume James is only considering reinventing this wheel because he is > not using C++. LLVM does not play nice with other languages because C++ > is quite uninteroperable. There are C bindings to LLVM that make it a lot > easier but, of course, they are far from complete. > > So I can fully appreciate the desire to do

On Mon, 5 Nov 2007, Kelly Wilson wrote: > I edited "The basic language, with its lexer" somewhat and I am > attaching a .html file. This is simply spelling/grammar editing and not > content. Thanks, I merged them in! > A simple diff should show the changes. Please let me know if this format > (ie. html file) is acceptable for your use. I don't think I changed >

Hi Chris, I edited "The basic language, with its lexer" somewhat and I am attaching a .html file. This is simply spelling/grammar editing and not content. It includes a few small changes to things like - ending a sentence with a noun and starting the next sentence with the same noun, clarifying some statements, not using "and" too many times in a sentence...little things

Reed, Are you working on a grammar of the LLVM syntax or also on a full semantics? Steve Zdancewic's group at U. Penn. is working on a formal operational semantics for LLVM. It is partially complete and Greg Morrisett at Harvard is planning to build further on it. Regards, --Vikram Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Oct 20,

Hello Tim, Thank you for getting back to me. The language grammar as defined by the LLVM Language Reference Manual [1] does not include the details of the LLVM IR parser reference implementation. The following extract from "lib/AsmParser/LLParser.cpp" illustrates that unnamed globals are allowed [2]. > /// ParseUnnamedGlobal: > /// OptionalVisibility (ALIAS | IFUNC) ...

Hello everyone, While developing a parser for LLVM IR, I seem to have stumbled upon a potential ambiguity in the LLVM IR assembly language grammar. Most likely there is something which I may have overlooked, so wanted to reach out to a more experienced crowed for some feedback. How would the following set of tokens be interpreted [1]? declare void @foo() unnamed_addr global i32 42 As far as

Hi all, i'm writing a TXL (http://www.txl.ca) grammar and a revamp of bison/flex grammar for LLVM. I've noticed an inconsistency regarding label naming conventions. For instance, the following is a segment of legit LLVM assembly (human-readable) IR: br i1 %38, label %17, label %39 ; <label>:39 ; preds = %._crit_edge ret void

On 2016-05-26 02:42, Tim Northover via llvm-dev wrote: > On 25 May 2016 at 16:10, Robin Eklind via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> declare void @foo() unnamed_addr >> global i32 42 > > Doesn't a global have to be named? The syntax in the IR reference > doesn't make it optional: > > @<GlobalVarName> = [Linkage]

Hello; I was planning to add a new instruction to the LLVM IR (and later to MIPS backend) for TLS(Thread level speculation) support. For this I tried to follow the steps described in http://llvm.org/docs/ExtendingLLVM dot html#instruction. But I could not find any llvm/lib/AsmParser/Lexer.l and llvm/lib/AsmParser/llvmAsmParser.y file in both the svn repository and the source code downloaded

Add a new lexer token, unused in the grammar, for the unknown lines in index files; this should allow to better handle such kind of parsing errors, removing the need to exit() directly (and leave things in an unclean state). --- builder/index-parse.y | 1 + builder/index-scan.l | 5 +---- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/builder/index-parse.y b/builder/index-parse.y

On 10/20/2011 07:42 AM, Duncan Sands wrote: >> For the level of specificity you're looking for, just the source code itself. The LLVM IR language documentation is not, and isn't intended to be, a true language standard document in the same way that the C or C++ standards are. For any given case, check the docs first, and if your question isn't answered there, check the source

Hello, Does a LL(k) grammar of LLVM assembly language exist somewhere ? Thanks JC

All, Just a note to let yo know that CVS Head has been changed so that the AsmParser no longer recognizes the "implementation" keyword and AsmWriter no longer generates it. The grammar has changed to require the "define" keyword for function definitions which obviates the need for the implementation keyword. This has been the case for a couple months now, but we never removed

I recently subscribed and saw in the archive that Eric Astor was asking for a formal grammar (unlikely the first time for such request.) Currently there are a few problems in making such a thing so I was curious if Mr. Gruber has made any thoughts about moving toward one? This would also allow a more ?clean? parser which would get rid of some of the current problems (bad nesting[^1],

hi, i was thinking of creating a WebDAV plugin for mongrel, but ran into an issue... the http parser hardcodes which request methods it considers valid, so it blocks non-standard request methods like MKCOL, PROPFIND, etc. i''m not familiar with the type of grammar being used for the parser, but is it possible to defer the request method validation to a later point, possibly inside the