similar to: [LLVMdev] Linking tools

On Fri, Jul 10, 2015 at 3:37 PM Russell Wallace <russell.wallace at gmail.com> wrote: > I'm trying to figure out exactly what the function and status of the > different linking tools is. The impression I get is: > > 1. For linking multiple bitcode (either binary or text format) files > together, llvm-link is the current and future intended tool. > > 2. For

On Fri, Jul 10, 2015 at 11:39 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Fri, Jul 10, 2015 at 3:37 PM Russell Wallace <russell.wallace at gmail.com> > wrote: > >> I'm trying to figure out exactly what the function and status of the >> different linking tools is. The impression I get is: >> >> 1. For linking multiple bitcode

On Mon, Jul 27, 2015 at 5:52 PM, Reid Kleckner <rnk at google.com> wrote: > I think your original description of the situation is accurate. llvm-link > will take multiple bitcode files and spit out a big ball o' bitcode, but > that's usually not sufficient for LTO, which is the main use case that we > want to support. > To be clear I understand you: the reason

On Mon, Jul 27, 2015 at 7:24 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > On Fri, Jul 10, 2015 at 11:39 PM, Eric Christopher <echristo at gmail.com> > wrote: > >> >> >> On Fri, Jul 10, 2015 at 3:37 PM Russell Wallace < >> russell.wallace at gmail.com> wrote: >> >>> I'm trying to figure out exactly what the

On Mon, Jul 27, 2015 at 9:59 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > On Mon, Jul 27, 2015 at 5:52 PM, Reid Kleckner <rnk at google.com> wrote: > >> I think your original description of the situation is accurate. llvm-link >> will take multiple bitcode files and spit out a big ball o' bitcode, but >> that's usually not sufficient for

Ah! Okay. A quick test of llvm-lto gets an error: llvm-lto: error adding file 'main.bc': Linking COMDATs named '??_7_Iostream_error_category at std@@6B@': invalid selection kinds! Would it be the case that llvm-lto is also deprecated in favor of the gold plugin? On Tue, Feb 10, 2015 at 4:47 PM, Teresa Johnson <tejohnson at google.com> wrote: > LTOCodeGenerator is used

I don't think I quite understand this... suppose for example you're trying to use an LLVM-based toolchain running on an x86 PC to write code for a device that uses an ARM processor in big endian mode, so you tell the LLVM code generator "generate code for ARM, big endian"... are you saying the optimizer will actually assume the target device is little endian because the

On Sat, Jun 4, 2011 at 5:21 AM, Charles Davis <cdavis at mymail.mines.edu> wrote: > You can link your bitcode together with glibc's bitcode by using the > llvm-link utility. Then you can run DCE over the bitcode with "opt -dce" > and cull all the functions you don't need. Right, that's still a reasonably straightforward solution for C... I think what I'm

I've finally developed what I think is a general solution to the problem of building existing Windows programs with clang: https://github.com/russellw/wic Using this, I've managed to run attempted builds of Python, Ruby and Perl. Python 2.7 works - it generates a python.exe that at least passes a preliminary smoke test. Perl generates an executable that crashes partway through the

Hi again, My point is that your code could not be written in C++ at this time because the only complete compiler for C++ is LLVM-GCC. It will do little endian optimizations on your x86 box and make the resultant bitcode file not work on the ARM processor. It is possible to write an endian-agnostic bitcode file but I don't think all modern LLVM compilers support it. Also the FAQ also

One issue I've been looking at with regard to using LLVM as a compiler backend is distribution of programs, particularly on Linux where different distributions have different binary package formats and it is usual to ship programs as source rather than binary; specifically, I'm looking at the general case where the end user may not have (the correct version of) LLVM installed, so the

I'm trying to use Clang on Windows to compile C++ to bitcode and then to an executable (with a view to carrying out some experiments on whole program optimization of the bitcode). When I use clang.exe, even with -D_HAS_EXCEPTIONS=0 -fms-compatibility -fms-extensions, I get errors: main-621e97.o : error LNK2019: unresolved external symbol _Unwind_Resume referenced in function main

Hello Russell, Major pitfall #1: LLVM-GCC does certain optimizations even if all of the optimizations are turned off. These include endian-specific optimizations so to use LLVM as a cross-architecture bitcode, you'll need to wait until Clang supports C++ fully or just stick to C programs for now. I've been looking forward to the day that LLVM can be used for cross-architecture

I'm trying to build LLVM 3.5.1 on Windows, almost successfully; the remaining stumbling block is getting static linking for release builds. The problem is that the .vcxproj is interpreted by msbuild to compile with the /MD option instead of /MT, as detailed in: https://stackoverflow.com/questions/28262372/getting-msbuild-to-use-mt-staticrelease Haven't got any answers on that question,

On Mon, Jul 27, 2015 at 9:52 AM, Reid Kleckner <rnk at google.com> wrote: > From the perspective of LTO, we just want users to be able > to add -flto to their compile and link lines, and make that produce a faster > executable, without the user ever being aware of the bitcode. For targets without GNU binutils and gcc driver support, has this goal been achieved? The few times

On Jun 3, 2011, at 9:27 PM, Russell Wallace wrote: > only having to write a parser for the ASCII version of bitcode > (dead easy) Don't do this. Seriously. Waste of time. There's a parser in llvm, it's pretty good at reading and writing bitcode. Just do your analysis using the llvm apis. -eric

With Clang, it's reasonably straightforward to compile a C/C++ file to bitcode. Is there a way to compile a program together with all the standard library functions it uses, to that format? That is, suppose you have hello.c that calls printf, how would you go about generating the bitcode representation of both the main function from hello.c, and printf itself (plus whatever other standard

I was testing my implementation of the usual ternary function just now, and it's giving the wrong answer; I would attribute this to an error in my parser/abstract syntax tree code, but looking at the output, as far as I can see, the intermediate code is correct at the point where I hand it to LLVM's JIT. Could someone look and see if I'm doing something wrong, misunderstanding the

On 12/22/15 4:45 AM, Russell Wallace via llvm-dev wrote: > Oh, I just came across Function::hasAddressTaken. Maybe I can just use > that instead? You could conservatively assume that any function that has its address taken has a pointer to it that escapes into memory or external code. To make things a little more accurate, you could scan the uses of any function for which

Following on from my last question, based on such information as I've been able to find on Google, I get the impression llvm-link is effectively deprecated / not actively maintained, because the focus of whole-program optimization is now on the gold plugin. Is that the case, or am I missing something? Running searches over the source tree, it seems the Linker class that actually implements