similar to: [LLVMdev] Extending AsmPrinter

On Monday 13 August 2007 15:50, Chris Lattner wrote: > > I also have a few questions on the general design of AsmPrinter. Why is > > runOnMachineFunction implemented for each target AsmPrinter? I would > > Historical reasons that aren't very good. Over the years, I've taken > several stabs at merging the asmprinters from various targets together. > They used to

On Tue, 14 Aug 2007, David Greene wrote: >> Yes, this is one advantage, another is that we wouldn't have to fix the >> same bug in multiple places :) > > Right. I've figured out where I need to make the changes in AsmWriterEmitter > given the current design. Ok, cool. > I'm trying out a few interesting things here based on custom streambufs. > It requires

On Wed, 2007-08-15 at 09:32 -0700, Chris Lattner wrote: > On Tue, 14 Aug 2007, David Greene wrote: > >> Yes, this is one advantage, another is that we wouldn't have to fix the > >> same bug in multiple places :) > > > > Right. I've figured out where I need to make the changes in AsmWriterEmitter > > given the current design. > > Ok, cool. >

On Fri, 10 Aug 2007, David Greene wrote: > I'm looking at extending AsmPrinter to pretty-print comments after > instructions (I'm adding the necessary fields to MachineInstr to do this). ok > I also have a few questions on the general design of AsmPrinter. Why is > runOnMachineFunction implemented for each target AsmPrinter? I would Historical reasons that aren't very

On Wednesday 15 August 2007 11:32, Chris Lattner wrote: > > I'm trying out a few interesting things here based on custom streambufs. > > It requires some surgery to AsmPrinters as a std::ostream won't work > > anymore due to the enhanced functionality of the custom streambufs. > > Is this still interesting to the larger LLVM community? One thing I have > >

>>> 1. The static constructor contortions in place to handle the >>> extremely >>> unlikely case of a static object constructor writing to one of the >>> standard streams. >> >> I also dislike this strongly, but it isn't really related. > > Isn't this the motivation behind "#include <iostreams> is hereby >

On Sunday 19 August 2007 19:34, Chris Lattner wrote: > How so? It's entirely possible to use FILE*'s without virtual > methods: just don't use iostreams. But you lose some flexibility. It may very well be a valid choice, but it needs to be carefully considered. But see below for more on dynamic vs. static polymorphism. > > What "overhead" are you talking

On Wednesday 15 August 2007 13:10, Reid Spencer wrote: > > It really depends on what you mean. I've found that iostreams are > > extremely slow, much slower than C stdio streams. Eventually I'd like to > > move them to stdio, not to more complex streambufs :) > > Eventually I'd like to move them to native syscalls adapted by > lib/System and suited to the

I'm writing a backend using a mid-October svn snapshot of LLVM. I'm having a hard time figuring out the relationship between my XXXAsmPrinter and MCAsmStreamer. Can someone explain what each is responsible for? Looking at the existing targets, the XXXAsmPrinter implementations seem to implement both the legacy "create a .s file" behavior, using printInstruction/printOperand/etc

Hi Tim, Thank you for your response. I need that immediate value latter to concatenate to registers' names (which I am doing during assembly printing). Also just Updating some status for my questioin: I have continued with using *Defs* list. It allows me to keep Registers as an implicit operands of /*MachineInstr*/ and later during its lowering pass them to the /*MCInstr*/. Now seems I need

Ryan, I've always been bothered by this tab character that doesn't come from the target. The line you're looking for I believe is from /utils/TableGen/AsmWriterEmitter.cpp at line 428. In my opinion the target should control whether a prefix is printed before an instruction. Thanks, Javier From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ryan

On Mon, 1 May 2006, [UTF-8] Rafael Esp?ndola wrote: > I am trying to write a skeleton of an ARM back end. I have declared > the following class > > class InstARM<dag ops, string asmstr, list<dag> pattern> : Instruction { > let Namespace = "ARM"; > > dag OperandList = ops; > let AsmString = asmstr; > let Pattern = pattern; > } > > and

On Wed, 15 Aug 2007, David Greene wrote: > I was just about to say that. While debugging my custom streambuf I had the > "opportunity" of investigating how libstdc++-v3 defines cout and friends. > It's not pretty. Basically, there's a stdio_sync_filebuf used as a proxy to > C's FILE *. Because stdio_sync_filebuf does no buffering itself (delegating > that to

On Mon, 20 Aug 2007, David Greene wrote: >>> what you're >>> getting at here. All buffering necessarily has some overhead. >> >> Buffering has overhead from copying data around. It doesn't matter >> whether you do in by using stdio buffering or by building your own >> buffers to avoid virtual method overhead. > > Sure. But that has nothing

Hi All, I'm working on various cleanups and simplifications to the asmprinters. One thing that is driving me nuts is that the asmprinters currently "reverse engineer" a lot of information when printing an operand that isel had when it created it. I'm specifically talking about all the suffixes generated by isel, like $non_lazy_ptr, @TLSGD, @NTPOFF, (%rip) etc. These

On Jul 9, 2009, at 5:34 PM, David Greene wrote: > Can someone explain what MCInst is vs. MachineIntr? Sure. MCInst is designed to be part of the "MC" set of libraries, which is stuff dealing with machine code. We're building a suite of assemblers and disassemblers out of this. MCInst is integral to this plan. For an assembler you have two pieces: 1. "Recognize"

Hi, While trying to debug a linking problem related to AsmPrinter, I found following lines in {srcdir}/configure file. if test -f ${srcdir}/lib/Target/${target_to_build}/*AsmPrinter.cpp ; then LLVM_ENUM_ASM_PRINTERS="LLVM_ASM_PRINTER($target_to_build) $LLVM_ENUM_ASM_PRINTERS"; It looks like the AsmPrinters are enumerated only if *AsmPrinter.cpp file is present in

Add new api xfs_admin to change parameters of an XFS filesystem. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/xfs.c | 78 ++++++++++++++++++++++++++++++++++++++++++ generator/generator_actions.ml | 21 ++++++++++++ gobject/Makefile.inc | 6 ++-- guestfs-release-notes.txt | 1 + po/POTFILES | 1 + src/MAX_PROC_NR

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along > with the rest of llvm. I'll work up a complete patch shortly. > > Btw, I'm curious how this happened. Do you have a stale CMakeCache.txt by > any chance? You might check the value for

Hello everyone! Could somebody, advice me what's wrong with my AsmPrinter? I've created ColdFireAsmPrinter.cpp file, and added initialization: extern "C" void LLVMInitializeColdFireAsmPrinter() { RegisterAsmPrinter<ColdFireAsmPrinter> X(TheColdFireTarget); } But, unfortunately, after build AsmPrinters.def doesn't contain LLVM_ASM_PRINTER(ColdFire). Maybe I've