search for: linker_private

...think this would set a bad precedent. There's nowhere else > (that I know of) where we accept two versions of assembly. The > LLParser is relatively easy to work with because it doesn't have that > kind of historical baggage. I can think of two precedents: attribute syntax and linker_private vs private. For attributes, we still parse the old syntax with the builtin non-string attributes after the ')' token, but that may be because it's just more readable. linker_private is still there because it's trivial to support. -------------- next part -------------- An HTML attac...

Hi, I'm trying to understand better how linker_private (and friends) work. From what I can understand from the manual (http://llvm.org/docs/LangRef.html#linkage_linker_private), it seems that a linker_private function cannot be removed by the optimizers. Only the linker can discard the symbol. However, I tested with 'opt -O1' and a fun...

This patch introduces a the new "linker_private_weak" linkage type. Why a new linkage type? The idea behind the "linker" linkage types is that they are used by the linker and then discarded. I.e., the symbols won't show up in the final linked image. In that regard, all "linker" linkage types are inherently "pri...

...innerExceptionTypesToCatch); (at the end i put the code for createCatchWrappedInvokeFunction, which is slightly modified to allow for things like printStr and createOurException that exists in the separate exception handling module to be used in the module Y) ; ModuleID = 'Y' @0 = linker_private constant [52 x i8] c"Gen: Executing finally block finally in invoke foo\0A\00" @1 = linker_private constant [52 x i8] c"Gen: Executing catch block typeInfo6 in invoke foo\0A\00" @2 = linker_private constant [52 x i8] c"Gen: Executing catch block typeInfo2 in invoke foo\0A\0...

On Jun 30, 2010, at 1:36 PM, Bill Wendling wrote: > This patch introduces a the new "linker_private_weak" linkage type. > > Why a new linkage type? The idea behind the "linker" linkage types is that they are used by the linker and then discarded. I.e., the symbols won't show up in the final linked image. In that regard, all "linker" linkage types are inherently...

On Jun 30, 2010, at 9:52 PM, Chris Lattner wrote: > On Jun 30, 2010, at 1:36 PM, Bill Wendling wrote: > >> I implemented the new linkage to have its own prefix from linker_private. As it currently stands, the symbol's prefix ("l") is the same for "linker_private" and "linker_private_weak". If this will always be the case, then I can remove the code in my patch that allows for a different prefix. > > I'm quite certain that it will...

...:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-f128:128:128-n8:16:32:64" target triple = "x86_64--linux-gnu" module asm "\09.ident\09\22GCC: (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 LLVM: exported\22" @.cst = linker_private unnamed_addr constant [15 x i8] c"aaaaaaaaaaaaaa\00", align 8 @.cst1 = linker_private unnamed_addr constant [15 x i8] c"bbbbbbbbbbbbbb\00", align 8 @.cst2 = linker_private unnamed_addr constant [24 x i8] c"a = %s, b = %s, c = %s\0A\00", align 8 define i32 @main(i32...

...vm/bindings/ocaml/llvm/llvm.ml Sun Dec 27 11:38:15 2009 -0800 @@ -42,13 +42,18 @@ | External | Available_externally | Link_once + | Link_once_odr | Weak + | Weak_odr | Appending | Internal + | Private | Dllimport | Dllexport | External_weak | Ghost + | Common + | Linker_private end module Visibility = struct @@ -79,6 +84,15 @@ | Nest | Readnone | Readonly + | Noinline + | Alwaysinline + | Optforsize + | Stackprotect + | Stackprotectreq + | Nocapture + | Noredzone + | Noimplicitfloat + | Naked end module Icmp = struct diff -r a8c05e69647e import/l...

...2:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-f128:128:128-n8:16:32:64" > target triple = "x86_64--linux-gnu" > > module asm "\09.ident\09\22GCC: (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 > LLVM: exported\22" > > @.cst = linker_private unnamed_addr constant [15 x i8] > c"aaaaaaaaaaaaaa\00", align 8 > @.cst1 = linker_private unnamed_addr constant [15 x i8] > c"bbbbbbbbbbbbbb\00", align 8 > @.cst2 = linker_private unnamed_addr constant [24 x i8] c"a = %s, b = > %s, c = %s\0A\00", align 8...

..._marker*, %struct._IO_FILE*, i32, i32, i64, i16, i8, [1 x i8], i8*, i64, i8*, i8*, i8*, i8*, i64, i32, [20 x i8] } %struct._IO_marker = type { %struct._IO_marker*, %struct._IO_FILE*, i32, [4 x i8] } @filename = unnamed_addr global i8* getelementptr inbounds ([11 x i8]* @.cst, i64 0, i64 0) @.cst = linker_private constant [11 x i8] c"fileio.txt\00", align 8 @.cst1 = linker_private constant [36 x i8] c"Test KernelGen support for File I/O\00", align 64 @.cst2 = linker_private constant [21 x i8] c"Usage: %s <szarray>\0A\00", align 8 @.cst3 = linker_private constant [2 x i8]...

...4-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-f128:128:128-n8:16:32:64" >> >> target triple = "x86_64--linux-gnu" >> >> module asm "\09.ident\09\22GCC: (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 >> LLVM: exported\22" >> >> @.cst = linker_private unnamed_addr constant [15 x i8] >> c"aaaaaaaaaaaaaa\00", align 8 >> @.cst1 = linker_private unnamed_addr constant [15 x i8] >> c"bbbbbbbbbbbbbb\00", align 8 >> @.cst2 = linker_private unnamed_addr constant [24 x i8] c"a = %s, b = >> %s, c = %s\...

...-42,13 +42,18 @@ > | External > | Available_externally > | Link_once > + | Link_once_odr > | Weak > + | Weak_odr > | Appending > | Internal > + | Private > | Dllimport > | Dllexport > | External_weak > | Ghost > + | Common > + | Linker_private > end > > module Visibility = struct > @@ -79,6 +84,15 @@ > | Nest > | Readnone > | Readonly > + | Noinline > + | Alwaysinline > + | Optforsize > + | Stackprotect > + | Stackprotectreq > + | Nocapture > + | Noredzone > + | Noimplicitfloat...

Hi Pablo, > I came across something that seems to be a bug in the dragonegg option that > emits LLVM IR. ¿Can anybody reproduce the error, or see what's wrong? I can't reproduce this on x86-64 linux with latest LLVM+dragonegg+gcc-4.6. ¿Should I > post it somewhere else in case it's really a bug? Thanks ahead! > > With this simple program: > * > #include

Hi all, I came across something that seems to be a bug in the dragonegg option that emits LLVM IR. ¿Can anybody reproduce the error, or see what's wrong? ¿Should I post it somewhere else in case it's really a bug? Thanks ahead! With this simple program: * #include <stdio.h> #include <string.h> int main(int argc, char** argv){ char a[8] = "aaaaaaa";

...ight and I think it was probably you! http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.6-test/builds/887 Here's a testcase. You can reproduce with "opt -instcombine". (The problem is that the code isn't expecting printf to return void). Ciao, Duncan. @.cst = linker_private unnamed_addr constant [8 x i8] c"A::A()\0A\00", align 8 define void @main() { call void (i8*, ...)* @printf(i8* getelementptr inbounds ([8 x i8]* @.cst, i64 0, i64 0)) ret void } declare void @printf(i8* nocapture, ...) nounwind

>> The days of the old .ll parser are long gone, but is it too late to >> change? In case it is not, the attached patches implement just that >> :-) > I'm afraid you need to provide syntax autoupgrade until 4.0 Why, we moved to doing autoupgrade via bitcode quiet some time ago. There were quiet a few format changes to the .ll in the process. Cheers, Rafael

...m to get emitted at all. maybe someone can adjust http://llvm.org/docs/SourceLevelDebugging.html#format_common_declare that the two llvm.dbg. functions need a !dbg line info associated with them? Code i used that does not work (but does if !dbg !14 is added): ; ModuleID = 'meh' @.str0 = linker_private constant [7 x i8] c"heh %b\00", align 1 @"\01L_OBJC_IMAGE_INFO" = internal constant [2 x i32] [i32 0, i32 16], section "__DATA, __objc_imageinfo, regular, no_dead_strip" @llvm.used = appending global [1 x i8*] [i8* bitcast ([2 x i32]* @"\01L_OBJC_IMAGE_INFO&quot...

...meter_dt = type { %struct.__st_parameter_common, i64, i64*, i64*, i8*, i8*, i32, i32, i8*, i8*, i32, i32, i8*, [256 x i8], i32*, i64, i8*, i32, i32, i8*, i8*, i32, i32, i8*, i8*, i32, i32, i8*, i8*, i32, [4 x i8] } %struct.__st_parameter_common = type { i32, i32, i8*, i32, i32, i8*, i32* } @.cst = linker_private constant [11 x i8] c"matmul.f90\00", align 8 define internal void @init_array.1535(%struct.FRAME.matmul* nest %CHAIN.41) nounwind uwtable { entry: %CHAIN.41_addr = alloca %struct.FRAME.matmul*, align 8 %i = alloca i32 %j = alloca i32 %D.1539 = alloca i32 %D.1553 = alloca i32...

...t_parameter_common, i64, > i64*, i64*, i8*, i8*, i32, i32, i8*, i8*, i32, i32, i8*, [256 x i8], i32*, > i64, i8*, i32, i32, i8*, i8*, i32, i32, i8*, i8*, i32, i32, i8*, i8*, i32, > [4 x i8] } > %struct.__st_parameter_common = type { i32, i32, i8*, i32, i32, i8*, i32* } > > @.cst = linker_private constant [11 x i8] c"matmul.f90\00", align 8 > > define internal void @init_array.1535(%struct.FRAME.matmul* nest > %CHAIN.41) nounwind uwtable { > entry: > %CHAIN.41_addr = alloca %struct.FRAME.matmul*, align 8 > %i = alloca i32 > %j = alloca i32 > %D.1539...