similar to: [RFC] Thoughts on a bitcode symbol table

On Fri, May 27, 2016 at 8:48 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > This is about https://llvm.org/bugs/show_bug.cgi?id=27551. > > Currently there is no easy way to get symbol information out of > bitcode files. One has to read the module and mangle the names. This > has a few problem > This would be great for ThinLTO as well: > > * During lto

Hi all, BitstreamReader is the only in-tree client of the DataStreamer and MemoryObject interfaces. In practice when using user-facing LLVM tools, the bitcode will normally either be in memory or in a file, so the best way to access it is through memory, either directly or memory mapped. As part of some refactorings I am making to BitstreamReader, I would like to simplify it by changing it to

And on a separate thread [0] Derek indicated he'd be fine with removing it. I'll leave this thread open until end of Monday to receive any other opinions, then proceed to remove it. Peter [0] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161024/400754.html On Fri, Oct 28, 2016 at 10:08 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > >

So far I'm really liking the new type system -- I've been able to simplify my code generator in a number of areas. And the IR is now vastly more readable, both in the debugger (using dump()) and when printing modules via llvm-dis. It's a tremendous improvement. I do have a few comments / questions: -- I think I may be misunderstanding how named structs are supposed to be combined in

hi all i m connecting to my samba server from a windows xp client. whenever i started my firewall script the client used to take 4 minutes to connect to the samba server and i run IRIS (sniffer) on my windows xp box it captures a packet as shown below ------------------------------------------------------------------------------------------------------------------------------------- OPTIONS /

Overview ======= We are planning to open source our internal implementation of Objective-C metadata reader library to LLVM. Unlike the C style objective-c metadata reader in llvm-objdump, it is designed to be a reusable C++ library to parse objective-c metadata from binaries with LLVM style error handling. The current implementation has an interface that resembles libObject in and it supports

Awesome! Thanks, Rafael On 28 October 2016 at 13:14, Peter Collingbourne <peter at pcc.me.uk> wrote: > And on a separate thread [0] Derek indicated he'd be fine with removing it. > I'll leave this thread open until end of Monday to receive any other > opinions, then proceed to remove it. > > Peter > > [0] >

Functions in LLVM IR have a function_entry_count metadata that is attached in PGO compilation. By using the entry count together with the block frequency info, the compiler computes the profile count of call instructions based on which the hotness/coldness of callsites can be determined. Experiments have shown that using a higher threshold for hot callsites results in improved runtime performance

> > I don't think these are really independent. Whether or not you need to emit > > a diagnostic depends on whether a caller can handle the corresponding error, > > which isn't something you know at the point where the error is raised. > But you do in the diag handler. For example, if you are trying to open > multiple files, some of which are bitcode, you know to

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

Hey: I spent sometime debugging this, it seems like editing ``llvm/tools/opt.cpp`` and move ``cl::ParseCommandLineOptions(argc, argv, "llvm .bc -> .bc modular optimizer and analysis printer\n");`` to the beginning of main() solved it for me. I'm not sure if this is a bug on LLVM side Zhang ------------------ Original ------------------ From: "Viktor Was BSc via

The fundamental problem here is that opt doesn’t use ExecutionEngine (because it has no need to), so trying to use ExecutionEngine (or any other bit of llvm that opt doesn’t use for that matter) in an opt plugin isn’t going to work. The solution I’d go with would be to build llvm with shared libraries (use –DBUILD_SHARED_LIBS=ON on the cmake command) then link the plugin against ExecutionEngine.

Hi Rafael, > The main thing I like about the diagnostic system is that it lets us > differentiate two related but independent concepts: > > * Giving the human using the program diagnostics about what went wrong. > * Propagating an error to the caller so that the upper library layer > can handle it or pass it up the stack. I don't think these are really independent. Whether

Hello, Disclaimer: I have no plan to break 3.x bitcode compatibility in any way. I’m experimenting with ideas to improve the current bitcode serialization and deserialization in general. I’m interested in improving the speed and the flexibility of the reader/writer, as well as making the code easier to deal with. My current griefs against our bitcode format are mainly the lack of built-in

I noticed on the wiki that some of the production hardware (compaq) doesnt have a power connector to my knowledge. I have a compaq c6400 that I would like to use for Asterisk. However all the drives are hot swap and the dual redundant power supply bay are not something i really feel like soldering wiring to. How are people getting around this? Is there a magic 'fan card' that has a

On 5/14/2012 10:28 AM, Jim Grosbach wrote: > > On May 14, 2012, at 10:21 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: > >> On 5/14/2012 9:51 AM, Jim Grosbach wrote: >>> >>>>> >>>>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>>>>

i am interested in getting lldb build using mingw (which i don't think has yet been done). to do so requires first building llvm in order to get the depended-upon clang library, et al. after installing mingw, i have performed the following steps, as these are what have been used to build lldb on linux (with the targets being my targets of interest): svn co

Hi This llvm-config --libs engine bcreader scalaropts <http://llvm.org/cmds/llvm-config.html> in website http://llvm.org/cmds/llvm-config.html But actually bcreader components is not there anymore. The new name of it is bitreader. I thinks this webpage may need to update and also. If i do "llvm-config --help". It will also show wrong component name in examples g++

On 19 September 2013 11:59, Jason Holajter <jholajter at arxan.com> wrote: > Hi, > > The behavior of llvm-ar appears to have changed such that the archive symbol > table no longer contains symbols contained within bitcode modules in the > archive. This behavior appears to have been changed with revision 184083 > when the internal implementation of llvm-ar was changed from

On 5/14/2012 10:40 AM, Ashok Nalkund wrote: >> >> Hm. OK, that's odd. It should change which constructor gets called in EngineBuilder::create() (which is in lib/ExecutionEngine/ExecutionEngine.cpp). Are you perhaps calling setUseMCJIT(true) after having already called create()? Can you step through EngineBuilder::create() and see what's happening there? >> >> -Jim