search for: emitted

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

...cantunwind record will stop the unwinder, and cantunwind will conflict > with the stack unwind information according to EHABI. Thus, we should not > emit cantunwind for the function with uwtable. Logan, Based on the current behaviour, you only need one flag: nounwind, which should only be emitted if -fno-unwind-tables is chosen AND the function can't unwind. Also, do not assume that EHABI behaviour in LLVM is currently correct, especially related to uwtable and nounwind. Those were made with the x86_64's ABI in mind, and have only interoperated seriously with DwarfCFIException unti...

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:

...waysinline+inline functions as available_externally definitions. The inliner is an SCC pass, and as such it does not process unreachable functions at all. This means that AlwaysInliner may leave some alwaysinline functions not inlined. If such function has an available_externally linkage, it is not emitted into the binary, and all calls to it are emitted as undefined symbol references. Some time ago I've made an attempt to add a DCE pass before the AlwaysInliner pass to fix this. Thst (a) caused a big churn in the existing tests (b) must be done at -O0 as well, which is probably undesirable an...

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

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 generated will be invalid )...

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