search for: emiting

Hi, I have been trying to get to grips with GCC's specs language in order to add COFF and ELF emission options. I have noticed that the '-emit-llvm-bc' option does not appear to work at all either with -S or without, giving :- llvm-gcc: unrecognized option '-emit-llvm-bc' Also this seems by default seems for '-emit-llvm' to produce a '.o' file instead of

Just thought I'd mention this to keep other people from stubbing their toes on it... Using llvm-gcc/llvm-g++ and -emit-llvm, you need to make sure to pass -S as well, like so: ./llvm-g++ -S -emit-llvm hello.cpp not: /llvm-g++ -emit-llvm hello.cpp I'm sure that's old news to most of the people on the list, but I thought it couldn't hurt to mention it in case other people happen

Requesting a new real buffer from the kernel and copying all the data is wasteful e.g. if only a few (but widely spread) vertices are accessed. --- src/gallium/drivers/nv50/nv50_context.h | 3 + src/gallium/drivers/nv50/nv50_vbo.c | 409 +++++++++++++++++++++++++++++-- 2 files changed, 394 insertions(+), 18 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_context.h

On Jun 9, 2008, at 11:32 AM, Jonathan Turner wrote: > Just thought I'd mention this to keep other people from stubbing > their toes on it... > > Using llvm-gcc/llvm-g++ and -emit-llvm, you need to make sure to > pass -S as well, like so: > > ./llvm-g++ -S -emit-llvm hello.cpp > > not: /llvm-g++ -emit-llvm hello.cpp > > I'm sure that's old news to

On 21 March 2014 18:47, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > * There's the table for ARM target: > > - no attribute => emit unwind table > - with nounwind => emit unwind table with cantunwind > - with uwtable => emit unwind table > - with uwtable+nounwind => emit unwind table WITHOUT the cantunwind > > The cantunwind record will stop the

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I think this is just 2. It uses .eh_frame for unwinding proper. The > only difference in .eh_frame is that there is a personality function > defined. If there is no debug information, it should still be possible to unwind the stack via the saved LR on the stack, no? If there is only line info, you

To add to what Duncan said, On Wed, Sep 16, 2009 at 1:28 PM, Aaron Gray <aaronngray.lists at googlemail.com> wrote: > Hi, > I have been trying to get to grips with GCC's specs language in order to add > COFF and ELF emission options. Good luck. :) > I have noticed that the '-emit-llvm-bc' option does not appear to work at > all either with -S or without, giving

I know right, but if I do -emit-llvm clang will emit an IR module as .ll file for each source I give him. So why can't it just emit the modules for the sources and then continue the compilation? I don't get the point of this error. Just for curiosity > On May 30, 2016, at 6:17 PM, David Blaikie <dblaikie at gmail.com> wrote: > > There is no single LLVM IR for the entire

On Feb 26, 2009, at 12:40 PM, Brice Lin wrote: > Sorry, I should have been clearer. My question deals with -emit-llvm > and -c, not -g and debug information. If you remove the -g flag from > the command I posted previously, the problem remains. Either way, I > updated my tree recently. > > Oddly enough, -emit-llvm affects the compile for me without -c or -S. > When I run the

Sorry, I should have been clearer. My question deals with -emit-llvm and -c, not -g and debug information. If you remove the -g flag from the command I posted previously, the problem remains. Either way, I updated my tree recently. Oddly enough, -emit-llvm affects the compile for me without -c or -S. When I run the aforementioned command, llvm-gcc outputs the following: ld warning: in

When I try to do clang++ main.cpp -emit-llvm without -S, clang says that he can’t: clang: error: -emit-llvm cannot be used when linking why can’t it emit the IR in a complete compilation process? Is there a particular technical reason or just to avoid confusing jobs? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, There is a problem with the handling of alwaysinline functions in Clang: they are not always inlined. AFAIK, this may only happen when the caller is in the dead code, but then we don't always successfully remove all dead code. Because of this, we may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function. Libc++ relies on the compiler

In CodeGen/DwarfWriter.cpp's EmitDebugLine file, these lines are causing havoc on Mac OS X systems: // If there are no lines to emit (such as when we're using .loc directives // to emit .debug_line information) don't emit a .debug_line header. if (SectionSourceLines.empty()) return; Basically, if there's a file with only data in it, we still need the debug_line

Hi John, llvm-gcc4 by default emits object files, just as gcc does. This is by design. If you want to get bytecode output you need to use the --emit- llvm-bc option. A complete list of the options that llvm-gcc4 supports can be obtained with "llvm-gcc -v --help" (lots of output). Here are the descriptions of the --emit-llvm options: -emit-llvm Emit LLVM code to the

Hi, I wanted to get the linked result in LLVM bitcode format. With LTO, this can be done by -flto -Wl,-plugin-opt,emit-llvm. Instead of generating native executables, it outputs a file with bitcode format. Does this still work with -flto=thin? -flto=thin -Wl,-plugin-opt,emit-llvm outputs a bitcode file, but its file size is too small, and does not contain all contents. What is the correct way

With LLVM 2.7, I see very inefficient emitting of zeros in .s files: test_: # @test_ .quad 0 # 0x0 .quad 0 # 0x0 .quad 0 # 0x0 .quad 0 # 0x0 .quad 0 # 0x0 .quad 0 # 0x0 [...] .quad 4 # 0x4 .quad 4

I'm interested in cleaning up the documentation for this, but it is in 4 different formats. From the makefile it looks like the .pod is the master. Do I need to do anything special after changing this to get it propagated elsewhere? On Jun 9, 2008, at 12:52 PMPDT, Dale Johannesen wrote: > On Jun 9, 2008, at 11:32 AM, Jonathan Turner wrote: >> Just thought I'd mention this

...vmla (NEON) instruction with cortex-a8 then shouldn't LLVM also emit vmla (NEON) instruction? Can someone please clarify on this point? The performance gain with vmla instruction is huge. Somewhere i read that LLVM prefers precision accuracy over performance. Is this true and hence LLVM is not emiting vmla instructions for cortex-a8? On Thu, Dec 19, 2013 at 6:41 AM, Kay Tiong Khoo <kkhoo at perfwizard.com>wrote: > Just to clarify: gcc 4.8.1 generates that fma at -O2; no FP relaxation or > other flags specified. > > > On Wed, Dec 18, 2013 at 6:02 PM, Kay Tiong Khoo <kk...

Hello! I'm interested in using LLVM as a target for a compiler I've written in common lisp (SBCL). While I looked at perhaps wrapping the LLVM C++ interface, wrapping C++ in, well, anything not C++ is a pain. Someone on IRC mentioned that they didn't think I'd miss out on any functionality by directly emitting IR, but suggested I query the list. Do I miss out on any optimizations

There is no single LLVM IR for the entire compilation process in such a command line - separate IR is created for each source file, an object file is created, then those (native, non-IR) object files are linked together. So it's somewhat a invalid concept. In your case, since there's only one file anyway, just add -c and you should be fine (your IR won't include the standard