search for: emitting

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

...hose flags, compilation stops earlier. -c -emit-llvm will produce llvm IR in its binary format (suitable for feeding into llc). It seems clear the current interface can be confusing; you are not the first. Perhaps -emit-llvm should be renamed to indicate it does not necessarily result in emitting llvm IR? -output-format-llvm? Seems pretty ugly, maybe someone can do better.

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

...the behaviour I want to create. But that can't be encoded in IR right now wrt. nothrow. These are the options: 1. no attr: don't emit tables 2. nounwind: emit CantUnwind 3. uwtable: emit table 4. uwtable + nounwind: emit table This is because uwtable means *also* debug/profiler use, and emitting CantUnwind could stop them from unwinding, since there is no information on how to continue unwinding the stack. The semantics I want is to be able to separate between EH unwinding and Debug/Profiler unwinding (even though they map to the same physical tables), so that we DO emit CantUnwind in tho...

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 never doing that - it has lots of functions in the headers marked this way and does _not_ export them from libc++.so. Current implementation in clang emits alwaysinline+inline fu...

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

...n stops earlier. -c -emit-llvm will produce llvm IR in > its binary format (suitable for feeding into llc). > > It seems clear the current interface can be confusing; you are not > the first. Perhaps -emit-llvm should be renamed to indicate it does > not necessarily result in emitting llvm IR? > -output-format-llvm? Seems pretty ugly, maybe someone can do better.

Hi all, Thanks for the info. Few observations from my side : LLVM : cortex-a8 vfpv3 : no vmla or vfma instruction emitted cortex-a8 vfpv4 : no vmla or vfma instruction emitted (This is invalid though as cortex-a8 does not have vfpv4) cortex-a8 vfpv4 with ffp-contract=fast : vfma instruction emitted ( this seems a bug to me!! If cortex-a8 doesn't come with vfpv4 then vfma instructions

...rested 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 or other neat trickery by using the IR directly? Does anyone know of any other platforms which directly target LLVM via emitting IR? Thanks, ...Eric Jonas

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