Potential ambiguity in the grammar of LLVM IR assembly

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 I can tell, both of the following representations are valid in the grammar [2]

declare void @foo() unnamed_addr
global i32 42

and [3]

declare void @foo()
unnamed_addr global i32 42

Is the grammar ambiguous, or is there something that I've overlooked?

Hope to hear back from you.

With kind regards,

Robin Eklind

[1]: poc/a.ll at master · mewspring/poc · GitHub
[2]: poc/a1.ll at master · mewspring/poc · GitHub
[3]: poc/a2.ll at master · mewspring/poc · GitHub

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.

To be fair, I believe it has been the case only for 2 weeks now (implemented in r269096).

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] ...

That was changed quite recently: rG32483a7641a4

I guess that means that the grammar is not ambiguous here anymore (if it was before).

-Manuel

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) ...
> /// OptionalLinkage OptionalVisibility OptionalDLLStorageClass
> /// ... -> global variable
> /// GlobalID '=' OptionalVisibility (ALIAS | IFUNC) ...
> /// GlobalID '=' OptionalLinkage OptionalVisibility OptionalDLLStorageClass
> /// ... -> 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 LLParser.cpp.

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?

Cheers
/u

[1]: http://llvm.org/docs/LangRef.html
[2]: https://github.com/llvm-mirror/llvm/blob/master/lib/AsmParser/LLParser.cpp#L432
[3]: https://github.com/mewspring/poc/blob/master/ll/b.ll

Hello Mehdi,

Thank you for bringing this to our awareness. I've been looking into the 3.8 release of LLVM. Would you happen to know if r269096 was part of this realese?

lli running on my system is capable of handling unnamed global variables, so I'd imagine so.

u@x1 ~> lli -version
LLVM (http://llvm.org/):
   LLVM version 3.8.0
   Optimized build.
   Built May 7 2016 (15:37:50).
   Default target: x86_64-unknown-linux-gnu
   Host CPU: broadwell

Cheers /u

I believe you're not on ToT, I get:

lli: b.ll:1:1: error: expected top-level entity
global i32 42

No it isn't in 3.8.
(I also mentioned in my email that it happened two weeks ago, which is obviously far after the 3.8 release).

Hello Manuel,

Thank you so much for bringing this to my attention. I wholeheartedly agree that the grammar is simplified by this change and welcome it with open arms.

Credit goes to Rafael for pushing this work.

This would indeed remove the language ambiguity as far as I'm aware.

Kindly
/Robin Eklind