similar to: [LLVMdev] [PATCH] Support asm comment output

On Jul 10, 2009, at 3:05 PM, David Greene wrote: > Here's the first of several patches to get comments into asm > output. This one > adds comment information to MachineInstructions and outputs it in the > generated AsmPrinters. This includes TableGen work to trigger the > comment > output in the right places. A couple of things are important to discuss: +

On Sunday 12 July 2009 18:56, Chris Lattner wrote: > On Jul 10, 2009, at 3:05 PM, David Greene wrote: > > Here's the first of several patches to get comments into asm > > output. This one > > adds comment information to MachineInstructions and outputs it in the > > generated AsmPrinters. This includes TableGen work to trigger the > > comment > > output

On Sunday 12 July 2009 18:56, Chris Lattner wrote: > A couple of things are important to discuss: > > + dynamic_cast<formatted_raw_ostream &>(O) << Comment(*c); > > We're trying to eliminate rtti, please don't add new uses of it. > Switching all of the asmprinter to statically use > formatted_raw_ostream would be appropriate. To separate comments,

On Jul 13, 2009, at 9:31 AM, David Greene wrote: >> A couple of things are important to discuss: >> >> + dynamic_cast<formatted_raw_ostream &>(O) << Comment(*c); >> >> We're trying to eliminate rtti, please don't add new uses of it. >> Switching all of the asmprinter to statically use >> formatted_raw_ostream would be

On Monday 13 July 2009 11:40, Chris Lattner wrote: > > I was attempting to reduce the number of files affected, but if you > > want this change I'll go ahead and do it. > > Makes sense, thanks. Please do it as a separate patch from the other > changes though since it will be large and mechanical. Ok, no problem. > > - Tag instructons with source line information

On Friday 13 November 2009 15:17, you wrote: > > Are these known to be broken right now? I get failure when using either. > > > > $ llc -march=arm -print-machineinstrs hw.bc > > Seems due to David's patches. Ok, it's faulting in SlotTracker with what looks like a bad Function. One of the Argument values is corrupted. I'm not abdicating responsibility, but at

Hi, When a user adds a comment i want to add the comment to the end of the comments list using ajax so there is no full page refresh. The code i have below adds the comment to the database but doesn''t update the comments div with the new comment. Can anyone help? This is my first use of rjs templates and i have read http://www.codyfauser.com/articles/2005/11/20/rails-rjs-templates

I''m running Typo, and after a comment is successfully posted, Typo runs this snippet of Javascript: new Effect.BlindDown($(''commentList'').lastChild); which throws the following error under Firefox 1.5rc1 (OSX) Error: element.style has no properties Source File: http://laughingmeme.org/javascripts/effects.js Line: 754 The problem being that lastChild() is returning

How do I make an ajax call and then update a div with a partial? I''ve tried this but it''s not working. Comment is created but the partial is not loaded. //view <a href="#" id="testlink">Testlink</a> <div id="commentlist"> </div> //controller def new @comment = Comment.new @comment.save

Building on OS X 10.7.1 with the standard toolchain, I have seen the following linker warnings going back a number of versions in trunk whenever I build an executable linked with LLVM: ld: warning: direct access in llvm::fouts() to global weak symbol llvm::formatted_raw_ostream::~formatted_raw_ostream() means the weak symbol cannot be overridden at runtime. This was likely caused by

On 28.12.2011, at 19:02, Jonathan Ragan-Kelley wrote: > Building on OS X 10.7.1 with the standard toolchain, I have seen the > following linker warnings going back a number of versions in trunk > whenever I build an executable linked with LLVM: > > ld: warning: direct access in llvm::fouts() to global weak > symbol llvm::formatted_raw_ostream::~formatted_raw_ostream()

Hi all, I'm trying to convert our code base from GCC 4.0 to LLVM (on mac OS X), and ran into a problem. In the past we used mach_override and the dynamic_cast source to override the built-in dynamic_cast operator to detect shared library issues (http://gcc.gnu.org/faq.html#dso). Basically we'd assert at runtime when a duplicated RTTI is found, giving us a chance to backtrace the offending

On Jul 13, 2009, at 10:02 AM, David Greene wrote: >>> - Tag instructons with source line information (customers really >>> want this). >> >> Right, that would be nice. This should be synthesizable from the >> DebugLoc on the instruction in the asm printer, no need to >> redundantly >> encode it into the comment field. > > Except the DebugLoc

Hi, Compiling on PP64/FreeBSd, I get several of these: /usr/home/kparzysz/bld.lv/tools/llvm-mc/Release+Asserts/llvm-mc.o: In function `llvm::formatted_raw_ostream::~formatted_raw_ostream()': llvm-mc.cpp:(.text.startup.main+0xe4): undefined reference to `LLVMInitializeARM64TargetInfo' llvm-mc.cpp:(.text.startup.main+0x154): undefined reference to `LLVMInitializeARM64TargetMC'

Thanks for the feedback! >> Does anybody have anything else they think should go into TGContext or >> any other responsibilities it should have? Or any feedback about the >> idea in general? > > All memory allocations should go into its bump pointer, RecordKeeper should as well. Any other global state that exist should also. Sounds good. >> I'm also hoping

HI Stefan, CC'ing Reid Kleckner, who might have some insight here, and llvm-dev as this may be of interest to other windows JIT users. I am facing the issue that C++ dynamic_cast doesn't work for types > loaded from object files with RuntimeDyLd. <snip> Do you think it is possible that RuntimeDyLd misses type info data in > the COFF file or doesn't wire it up

Just noticed that when we generate a custom lowering for some atomics that we forgot to transfer the MemOperand to the new instruction that touches memory. -- Mon Ping Index: lib/Target/X86/X86ISelLowering.cpp =================================================================== --- lib/Target/X86/X86ISelLowering.cpp (revision 53702) +++ lib/Target/X86/X86ISelLowering.cpp (working copy) @@

Hi all, I'm sure that the last thing that you want to think about is TableGen's guts, but I'm pursuing a course in bringing TableGen up to snuff with the rest of LLVM. Basically, I would like to introduce a "TGContext" class (by analogy with LLVMContext) to harbor a proper unique'd type system and BumpPtr allocate all of TableGen's data (RecTy's, Record's,

LLVM has a relatively large number of proprietary replacements for standard C++ functions and classes. One of these is dyn_cast to replace dynamic_cast. The two calls appear to be semantically equivalent; the only difference that I can see is that dyn_cast reportedly works on classes that have no v-table [1]. Could someone please explain why I should use dyn_cast instead of dynamic_cast?

It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory. -Chris On Oct 3, 2012, at 9:39 PM, Sean Silva <silvas at purdue.edu> wrote: > Thanks for the feedback! > >>> Does anybody have anything else they think should go into TGContext or >>> any other responsibilities it should have? Or any