similar to: [LLVMdev] Saving code for later execution

On Aug 25, 2009, at 1:04 AM, Albert Graef wrote: > . For many applications > other than LLVM itself, the basic LLVM <=2.5 interface which just > overwrites existing files is all that's ever needed. On LLVM trunk, raw_fd_ostream is now back to overwriting files by default, as it is the unanimous preference among in-tree users (and out-of-tree users that I'm aware of). Dan

Hi - attached is a patch to enable building DragonEgg (x86_64) for LLVM3.3 and LLVM3.4. That is, add these changes to the 3.3 release, and it becomes possible to build DragonEgg against a llvm3.4 compiler. Regards, Richard Gorton Cognitive Electronics rcgorton at cog-e.com ---------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

Hi Dan, lld takes a -emit-yaml option, which emits the intermediate representation(atoms) in YAML form. By default output goes to stdout, the user can control it by using the -o option too. The way its handled is, similiar to this piece of pseudo-code if (dash_o_option) outputFile = dash_o_option->value() else outputFile = "-" When lld tries to mix things that go to

Hi, When I run the below example, it results in :- hello world LLVM ERROR: IO failure on output stream. Testcase :- #include <llvm/Support/raw_ostream.h> int fn() { std::string errorInfo; llvm::raw_fd_ostream out("-", errorInfo); out << "world\n"; return 0; } int main(int argc, char **argv) { llvm::outs() << "hello\n"; fn();

On 06/19/2010 14:03, Yuri wrote: > This new option (--jit-emit-debug-function-range) will allow to output > function information for memory ranges that functions occupy in memory > while they run in JIT. File format generated is like this: > ... > 0x5000000 0x5001000 function_name_is_here > ... > > This feature is useful for external tools like valgrind and >

Hi Dan, The other messages, need to go to stdout as well. Using stderr to output for a switch like --verbose is wrong in my opinion. On 8/14/2013 4:44 PM, Dan Gohman wrote: > Would it be appropriate for lld's other output to go to standard error > instead of standard output, since standard output may be used for YAML > output? > > Dan > > On Wed, Aug 14, 2013 at 12:53

Hello, using the LLVM API, I've build one very simple function that adds two ConstantInts and returns the result. I noticed that, when I emit IR code, it is optimized to a simple "ret i16 42" when I add 40 and 2. I'd like to see the operations that are necessary to compute the result, though. Can I somehow disable this optimization in the pass, leading to more verbose IR code?

The high-level answer is that library code shouldn't hardcode output paths, including "-" and including using llvm::outs(). Library code should (in general) instead accept an ostream in its API and write to wherever it is being asked to write. If this is followed, the only place in any program using llvm::outs() is code which is not part of a "library" -- i.e. it is the

Albert Graef wrote: > I understand that. But in this specific case it would be very easy to > maintain, no? FWIW, suggested patch attached. That makes the LLVM 2.5 style raw_fd_ostream constructor work with the trunk (r80036). Note that this just adds a second constructor, existing code will continue to work as before. I'd be happy to prepare an analogous patch for the 2.6 release

Would it be appropriate for lld's other output to go to standard error instead of standard output, since standard output may be used for YAML output? Dan On Wed, Aug 14, 2013 at 12:53 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Dan, > > lld takes a -emit-yaml option, which emits the intermediate > representation(atoms) in YAML form. > > By default

Dan Gohman wrote: > > On Aug 25, 2009, at 1:04 AM, Albert Graef wrote: >> . For many applications >> other than LLVM itself, the basic LLVM <=2.5 interface which just >> overwrites existing files is all that's ever needed. > > On LLVM trunk, raw_fd_ostream is now back to overwriting files by > default, as it is the unanimous preference among in-tree users

Previously I had asked how to write then read back IR to/from a file. The write code looked like: LLVMContext ctx; SMDiagnostic diag; Module *m = ParseIRFile( "my_file", diag, ctx ); However, the code I'm trying to retrofit LLVM IR into passes me just a std::ostream&. How can I read IR from a std::ostream? I figured out how to use raw_os_ostream to adapt a

Standard error is what many tools, including clang for example, use for their --verbose output. This is appropriate because it leaves standard output available for regular output data, which the user may wish to capture in a file or a pipe. Dan On Wed, Aug 14, 2013 at 2:48 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Dan, > > The other messages, need to go to

On Aug 25, 2009, at 3:40 PM, Albert Graef wrote: > Albert Graef wrote: >> I understand that. But in this specific case it would be very easy to >> maintain, no? > > FWIW, suggested patch attached. That makes the LLVM 2.5 style > raw_fd_ostream constructor work with the trunk (r80036). Note that > this > just adds a second constructor, existing code will continue to

IRBuilder is a templated class, and one of the template arguments is the constant folder to use. By default it uses the ConstantFolder class which does target-independant constant folding. If you want to disable constant folding you can specify the NoFolder class instead, i.e. declare the builder as follows: IRBuilder<true, llvm::NoFolder> builder(body) On 26 Nov 2013, at 19:23, Daniel

Chris Lattner wrote: > Given that we don't guarantee backwards compatibility and prefer to keep > our APIs clean and tidy, why should we take this? I already said that: To make it easier for out-of-tree frontends to support at least the last few LLVM versions. If that's a low priority then don't. I can live with it. Please understand that I don't complain about API breakage

Hi, I'm trying to inline function defined in another bitcode module via bitcode modification. I'm linking multiple bitcode modules, setting inline related attributes, applying -always-inline pass, but then debug info error occurs. It seems debug info metadata isn't properly updated on inlining. How can I fix it? I'm using LLVM 3.8.1 on OS X (On below example target is Android but

Dagobert Michelsen wrote: > There compilation on Solaris 10 Sparc with Sun Studio 12 gives the following compile errors: > > > CC bitreader.lo > > "bitreader.c", line 494: warning: implicit function declaration: MIN > > CC bitwriter.lo > > "bitwriter.c", line 273: reference to static identifier "bitwriter_grow_" in extern

Ben Allison wrote: > As mentioned before, this removes some of the 'inline' from the bitreader > and bitwriter functions that were used in another translation unit. I'm > surprised that this code works on other platform. It must be a bug in > GCC, or maybe deliberately non-standard behavior. See 6.7.4 of the C99 > spec for details. I've read section 6.7.4 from

Pending positive confirmation in http://llvm.org/PR2886, I'd recommend that r57974 and r57976 be pulled into the 2.4 release branch and configure regenerated there. Begin forwarded message: > From: Gordon Henriksen <gordonhenriksen at mac.com> > Date: October 22, 2008 08:40:40 EDT > To: llvm-commits at cs.uiuc.edu > Subject: [llvm-commits] [llvm] r57974 -