[llvm-dev] Potential ambiguity in the grammar of LLVM IR assembly

Robin Eklind via llvm-dev llvm-dev at lists.llvm.org
Wed May 25 18:59:45 PDT 2016

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 

The following extract from "lib/AsmParser/LLParser.cpp" illustrates that 
unnamed globals are allowed [2].

 > /// ParseUnnamedGlobal:
 > ///   OptionalVisibility (ALIAS | IFUNC) ...
 > ///   OptionalLinkage OptionalVisibility OptionalDLLStorageClass
 > ///                                                     ...   -> 
global variable
 > ///   GlobalID '=' OptionalVisibility (ALIAS | IFUNC) ...
 > ///   GlobalID '=' OptionalLinkage OptionalVisibility 
 > ///                                                     ...   -> 
global variable

Also, using lli to interpret the following example program [3] produces 
the status code 42.

global i32 42
define i32 @main() {
	%foo = load i32, i32* @0
	ret i32 %foo

As neither the LLVM Language Reference Manual, nor the comments of the 
LLVM IR reference implementation, include a full EBNF of the language 
grammar, one has to make educated guesses and cross-reference 
information from LangRef.html, comments in LLParser.cpp and the code in 

I'd love to see an EBNF grammar for LLVM IR at some point in the future, 
as this would open up for very interesting possibilities.

Given that global variables may be unnamed, does the unnamed_addr 
introduce an ambiguity in the LLVM IR grammar?


[1]: http://llvm.org/docs/LangRef.html
[3]: https://github.com/mewspring/poc/blob/master/ll/b.ll

On 05/26/2016 02:42 AM, Tim Northover 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] [Visibility] [DLLStorageClass]
> [ThreadLocal] ...
> Cheers.
> Tim.

More information about the llvm-dev mailing list