similar to: [LLVMdev] Inconsistencies or intended behaviour of LLVM IR?

Hello Sean, Thank you for your reply. I'll give your suggestion to item 6 and 7 a try tonight. I'll start a compilation and let it run throughout the night. My laptop (x61s) is 8 years old by know, so compiling LLVM takes a little time :) Regarding item 8. I don't know if anyone is using "": in the wild so fixing the implementation might make sense. If not the

On Wed, Jan 28, 2015 at 6:28 PM, Robin Eklind <carl.eklind at myport.ac.uk> wrote: > Hello Sean, > > Thank you for your reply. I'll give your suggestion to item 6 and 7 a try > tonight. I'll start a compilation and let it run throughout the night. My > laptop (x61s) is 8 years old by know, so compiling LLVM takes a little time > :) > This is why I did so much

On Mon, Feb 2, 2015 at 9:51 AM, Robin Eklind <carl.eklind at myport.ac.uk> wrote: > (forgot to cc the list) > > Answers, questions and assumptions are inlined in the response. > > If someone with knowledge of the LLVM IR type system could take a look at > my assumptions below I'd be very happy. > > On 01/30/2015 02:24 AM, Sean Silva wrote: > >> On Thu,

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

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.

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

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]

> 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

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 at x1 ~> lli -version LLVM (http://llvm.org/): LLVM version 3.8.0 Optimized build. Built May 7 2016

On Mon, 04 Jun 2012 18:37:31 +0100 Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > So here is a new proposal: > > !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* } > > alloc_size_fn and offset_fn are functions that return either i32/i64 > depending on the platform, and they must have the same number of > arguments (not necessarily the same as the

On 01/08/2010 02:10 PM, John McCall wrote: > 'llc' is an IR-to-assembly compiler; at -O3 it does some pretty neat > machine-code and object-file optimizations, but it does not apply > high-level optimizations like CSE or inlining. 'opt' is the tool > which does IR-to-IR optimization. A vital clue, but I'm still not getting it: --- gemini:~/Projects/Nil/nil(0)$

Dustin Laurence wrote: > On 01/08/2010 02:10 PM, John McCall wrote: > > >> 'llc' is an IR-to-assembly compiler; at -O3 it does some pretty neat >> machine-code and object-file optimizations, but it does not apply >> high-level optimizations like CSE or inlining. 'opt' is the tool >> which does IR-to-IR optimization. >> > > A

>> Hi, >> >> So here is a new proposal: >> >> !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* } >> >> alloc_size_fn and offset_fn are functions that return either i32/i64 >> depending on the platform, and they must have the same number of >> arguments (not necessarily the same as the as allocation function). >> The parameters are

On 23/10/12 01:30, Michael Spencer wrote: > On Mon, Oct 22, 2012 at 7:53 AM, r4start <r4start at gmail.com> wrote: >> On 20/10/12 03:15, Michael Spencer wrote: >>> On Fri, Oct 19, 2012 at 2:55 AM, r4start <r4start at gmail.com> wrote: >>>> Hi all. >>>> >>>> While compiling next code >>>> @A = weak unnamed_addr constant {

On Wed, Oct 31, 2012 at 9:41 AM, r4start <r4start at gmail.com> wrote: > On 24/10/12 17:03, r4start wrote: >> >> On 23/10/12 01:30, Michael Spencer wrote: >>> >>> On Mon, Oct 22, 2012 at 7:53 AM, r4start <r4start at gmail.com> wrote: >>>> >>>> On 20/10/12 03:15, Michael Spencer wrote: >>>>> >>>>> On

On Fri, Jun 2, 2017 at 12:18 PM, Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Why do we need a custom dumping format for the summary? Since we already > need the YAML format anyway, wouldn't it be better to extend that to cover > the entire summary? > IMO it is useful/convenient to be able to see the summary in the llvm-dis output. Teresa >

Hi, So here is a new proposal: !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* } alloc_size_fn and offset_fn are functions that return either i32/i64 depending on the platform, and they must have the same number of arguments (not necessarily the same as the as allocation function). The parameters are given in the metadata as well. To accommodate the common case, offer_fn can be

Hey all, Below is the proposed format for the dump of the ThinLTO module summary in the llvm-dis utility: > ../build/bin/llvm-dis t.o && cat t.o.ll ; ModuleID = '2.o' source_filename = "2.ll" target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @X = constant i32 42, section "foo", align

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> John McCall wrote: <blockquote cite="mid:FAB334D8-72D0-40FB-B133-A9430870B701@apple.com"

Hi, When I tried to use the latest version of LLVM tools (clang as the frontend) to compile and link a project with multiple c files, it appears that each of the generated .bc file contains a definition of pthread_equal, resulting llvm-link failure with error message "multiply symbols defined". I tried but did not get any answer on the web. So I turn to you for help. Here is the