Robin Eklind via llvm-dev
2016-May-25 23:10 UTC
[llvm-dev] 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]: https://github.com/mewspring/poc/blob/master/ll/a.ll [2]: https://github.com/mewspring/poc/blob/master/ll/a1.ll [3]: https://github.com/mewspring/poc/blob/master/ll/a2.ll
Tim Northover via llvm-dev
2016-May-26 00:42 UTC
[llvm-dev] Potential ambiguity in the grammar of LLVM IR assembly
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 42Doesn'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.
Mehdi Amini via llvm-dev
2016-May-26 01:55 UTC
[llvm-dev] Potential ambiguity in the grammar of LLVM IR assembly
> On May 25, 2016, at 5:42 PM, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> 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:To be fair, I believe it has been the case only for 2 weeks now (implemented in r269096). -- Mehdi> > @<GlobalVarName> = [Linkage] [Visibility] [DLLStorageClass] > [ThreadLocal] ... > > Cheers. > > Tim. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Manuel Jacob via llvm-dev
2016-May-26 01:59 UTC
[llvm-dev] Potential ambiguity in the grammar of LLVM IR assembly
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] [Visibility] [DLLStorageClass] > [ThreadLocal] ...That was changed quite recently: http://reviews.llvm.org/rL269096#c4361726 I guess that means that the grammar is not ambiguous here anymore (if it was before). -Manuel> Cheers. > > Tim. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Robin Eklind via llvm-dev
2016-May-26 01:59 UTC
[llvm-dev] Potential ambiguity in the grammar of LLVM IR assembly
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 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. >
Reasonably Related Threads
- Potential ambiguity in the grammar of LLVM IR assembly
- Potential ambiguity in the grammar of LLVM IR assembly
- Potential ambiguity in the grammar of LLVM IR assembly
- Potential ambiguity in the grammar of LLVM IR assembly
- Potential ambiguity in the grammar of LLVM IR assembly