similar to: [LLVMdev] boost shared pointer & llvm

hi, thanks for your quick replies. -DBOOST_SP_USE_PTHREADS worked indeed. however, i didn't measure the performance but i would assume that the boost developers had a good reason for using assembler in this context. will llvm ever support inline assembly? is there anybody who is working on that? thanks, stefan. On Tuesday 21 July 2009 01:54:20 pm Vladimir Prus wrote: > Stefan Weigert

Stefan Weigert wrote: > hi, > > when using the execution engine (no matter, if JIT or Interpreter) i get the > following assertion as soon as i use boost::shared_ptr: > > /build/buildd/llvm-2.5/lib/Target/X86/X86CodeEmitter.cpp:522: > void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const > llvm::TargetInstrDesc*): Assertion `0 &&

Hello everyone, I bring to discussion the necessity/design of a new type of smart pointer. r215176 and r217791 rise the problem, D5443 <http://reviews.llvm.org/D5443> is devoted to the solution. r215176 applies several temporary ugly fixes of memory leaks in TGParser.cpp which would be great to be refactored using smart pointers. D5443 <http://reviews.llvm.org/D5443> demonstrates

On Thu, Sep 25, 2014 at 1:44 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 25 September 2014 06:16, David Blaikie <dblaikie at gmail.com> wrote: > > I can go & dredge up some examples if we want to discuss the particular > > merits & whether each of those cases would be better solved in some other > > way, but it seemed pervasive enough in the

Hi, In the code below, MyNamespace::MyClass_ptr will be named "struct.boost::MyClass_ptr" by llvm-g++, and not "struct.MyNamespace::MyClass_ptr" as I expected. I observed this with the real boost::shared_ptr but used the code below (also attached as structnametest1.cc) on the demo page (http://llvm.org/demo/index.cgi) to reproduce the behavior. When I extended my test code

Hi, After Bob fixed the two-address format of the ARM ldm/stm instructions, a problem remains. The load multiple instruction looks like: // A list of registers separated by comma. Used by load/store multiple. def reglist : Operand<i32> { let PrintMethod = "printRegisterList"; } def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, reglist:$dsts,

On Mar 19, 2010, at 7:46 AM, Jakob Stoklund Olesen wrote: > Hi, > > After Bob fixed the two-address format of the ARM ldm/stm instructions, a problem remains. The load multiple instruction looks like: > > // A list of registers separated by comma. Used by load/store multiple. > def reglist : Operand<i32> { > let PrintMethod = "printRegisterList"; > }

Hi there, I think I've found a bug in the x86 JIT. I get an assertion failure when using thread-local variables and the fast emitter. It only happens with the JIT, the fast emiiter and thread-locals. (The IR passes the verifier) Here's the failure: X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*):

Hi Bill, I am using the following version of BuildMI : MachineInstrBuilder BuildMI(MachineFunction &MF, const TargetInstrDesc &TID, unsigned DestReg) I do the following : void createInstrs(std::vector<MachineInstr *>& ilist) { Machine Instr *mi; mi = BuildMI(MF, someTID, somereg);

Hi to everyone, while working with the machine scheduler for a personal project, I came up with the necessity of inserting a backup boundary in the MachineSchedulerStrategy -- specifically, the PostGenericScheduler -- to hold a copy the scheduler's state, in order to implement a really trivial (and really inefficient) backtracking mechanism. This approach leads to a subtle "segmentation

Hi Susan, > 1. I tried running the PBQP allocator (as a dynamic pass), but that didn't > work.... Can you tell from this what I'm doing wrong? > The PBQP allocator is built into the LLVM CodeGen library, so the "-regalloc=pbqp" option is already available in llc. If you've built a copy of the PBQP allocator in a separate library it will try to re-register

> You have to create one! Take a look at PPCHazardRecognizers.cpp > and SPUHazardRecognizers.cpp for examples. > If you can, contribute it back! :) There is also generic hazard recognizer which works on top of instruction itineraries. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

How do I determine what type of register(i.e. i32, f32, etc..) I am accessing from a MachineOperand? I.e. how do I get to the MVT struct, or equivalent information, from a MachineOperand object? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596

Evan, Any plans to add it any time soon? It would be really appreciated. Evan Cheng wrote: > X86 JIT does not yet support TLS. > > Evan > On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote: > >> Hi there, >> >> I think I've found a bug in the x86 JIT. I get an assertion failure >> when >> using thread-local variables and the fast emitter.

hello, i am new to llvm and can't manage to compile the gcc backend. my steps: i compile the llvm-source first as suggested in "README.LLVM" that works fine and without any issues. then i make a new dir called build. from there i do the following: stefan at ubuntu:~/programs/llvm/build$ ../llvm-gcc4-1.9.source/configure --enable-languages=c,c++ --prefix=/usr/local/

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

Lang - I've made some progress writing my register allocator, but now I'm stuck. I have 2 questions for you: 1. I tried running the PBQP allocator (as a dynamic pass), but that didn't work. When I type this: llc -f -load Debug/lib/regalloc.so -regalloc=pbqp simple.bc I get the following error: llc:

why llvm contains IntrusiveRefCntPtr instead of using only std::shared_ptr? IntrusiveRefCntPtr widely used in llvm and clang source code. Due to better performance? for example in main func of clang frontend: int cc1_main(ArrayRef<const char *> Argv, const char *Argv0, void *MainAddr) { ensureSufficientStack(); std::unique_ptr<CompilerInstance> Clang(new CompilerInstance());

Am 29.08.19 um 12:07 schrieb Jonathan Wakely: > On Thu, 29 Aug 2019 at 10:15, Christian Schneider > <cschneider at radiodata.biz> wrote: >> >> Hello, >> I just discovered, that, when using enable_shared_from_this and >> inheriting it privately, this fails at runtime. >> I made a small example: >> >> #include <memory> >> #include

Hi, I would like to use std::shared_ptr in my pass. However I'm facing a problem wrt RTTI. If I have a code like: std::shared_ptr<BaseClass> x(new DerivedClass()); ... std::shared_ptr<DerivedClass> p = std::dynamic_pointer_cast<DerivedClass>(x); It does not compile since the default RTTI infrastructure is not used by LLVM. Also, it's not clear to me if the