search for: asmstreamer

On Friday 17 August 2007 13:17, Chris Lattner wrote: > On Fri, 17 Aug 2007, David Greene wrote: > >> Posix is pretty available, what system doesn't have them? > > > > Windows, for one. If POSIX is ok, it's better in my mind to just > > directly > > Windows has POSIX calls. Ok, I'll admit I don't know a lot about what's available there.

On Fri, 17 Aug 2007, David Greene wrote: >> Posix is pretty available, what system doesn't have them? > > Windows, for one. If POSIX is ok, it's better in my mind to just directly Windows has POSIX calls. > use open, write and friends, which is what I do now. Going the cstdio > route should only be done for portability reasons to support non-POSIX > systems. I

...8620 and both produce this log with gcc-4.6.0 on FreeBSD-8.2-STABLE amd64: gmake[2]: Entering directory `/usr/home/yuri/llvm-svn/llvm-objects/lib/CodeGen' llvm[2]: Compiling LLVMTargetMachine.cpp for Release build /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/LLVMTargetMachine.cpp:253:3: error: ‘AsmStreamer’ does not name a type /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/LLVMTargetMachine.cpp:257:3: error: ‘AsmStreamer’ does not name a type /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/LLVMTargetMachine.cpp:260:37: error: ‘getTarget’ was not declared in this scope /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/L...

...e TargetMachine, create FunctionPassManager, call TargetMachine::addPassesToEmitFile(), add my own MyObjectCodeWriter pass and run passes. But since LLVM 2.7 TargetMachine::addPassesToEmitFile (as implemented in LLVMTargetMachine child class) adds its own final pass (AsmPrinter) paired with either AsmStreamer, MachOStreamer or NullStreamer. I cannot pass my own descendant of MCStreamer class. Now we've got predefined set of final passes instead of free choice. AFAIK to get object code file I have to feed emitted code through my own MyMCStreamer class. The only sane option I see is to take assembly...

On Fri, 17 Aug 2007, David Greene wrote: > Ah. Basically operator<< for FILE*. I don't see a lot of benefit to > redefining operator<< for every type just to avoid ostreams. The > problem isn't basic_ostream _per_se_. There are two issues we're > worried about: The problem is basic_ostream and the design of the whole iostreams library. Use of virtual base

...unctionPassManager, call TargetMachine::addPassesToEmitFile(), add my > own MyObjectCodeWriter pass and run passes. > > But since LLVM 2.7 TargetMachine::addPassesToEmitFile (as implemented in > LLVMTargetMachine child class) adds its own final pass (AsmPrinter) > paired with either AsmStreamer, MachOStreamer or NullStreamer. I cannot > pass my own descendant of MCStreamer class. Now we've got predefined set > of final passes instead of free choice. LLVM 2.7 doesn't have final support for this. The idea is that we'd add ELF and PECOFFStreamers as well, or parameterize...

Hi Craig and Rail, At Movidius, we have had to make a few changes to ‘MCAsmStreamer’ to support our assembler which is not ‘gas’ compliant. Earlier versions of LLVM (3.1 and 3.2) did have a separate header for ‘MCAsmStreamer’, and we had previously sub-classed this. The following are modifications that we have had to make because although ‘MCAsmStreamer’ does most of what...

...PassConfig::addPreEmitPass() and it will currently be the last thing to run before the asm printer, but I don’t know if thats a guarantee or not. In theory anyone could add something after the call to preEmitPass and before this code FunctionPass *Printer = getTarget().createAsmPrinter(*this, *AsmStreamer); PM.add(Printer); but if they do you can shout loudly :) Thanks, Pete > > -Andy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...another possibilities ? - Currently I'm using the LLVMTargetMachine::addPassesToEmitFile with FileType set to CGFT_ObjectFile, and with the triple environment name hack, I am able to create the correct streamer : if (Triple(TargetTriple).getEnvironmentName().equals("JIT")) { AsmStreamer.reset(createJITStreamer(*Context, *TAB, Out, MCE)); } else { AsmStreamer.reset(createMachOStreamer(*Context, *TAB, Out, MCE)); } What do you think ? Do you consider this to be acceptable ? Or just horrible ? - MCObjectWriter::Write8 and MCObjectWriter::WriteBytes are designed to wri...

On Thu, Jan 21, 2016 at 5:03 PM, Craig Topper <craig.topper at gmail.com> wrote: > I dont' know why its final. That routine is just a method to force the > current write pointer to a specific alignment. Shouldn't you be changing > the callers to give you the alignment you want or don't want. > > > > -- > ~Craig > It looks like the callers get their

I do have an opinion, but don't have enough time to comment in much depth. The approximate approach I had in mind sounds like what you describe, though, the JITObjectWriter is the core piece, the other pieces probably fall into place as it becomes obvious if they are needed. It should be pretty straightforward to bring up something which works for running code with no external symbols, if you

2010/10/21 Jason Kim <jasonwkim at google.com>: > Of the 45 remaining, there are 4 interesting uses in MCAsmStreamer.cpp > - (I suppose for emitting data constants in a cross platform manner) > The other remaining uses are in AsmPrinter, again to do cross platform things. > It seems a bit strange to use a high level hammer to do ballpeen > work..... But when in Rome.... :-) Hi Jason, Are you printin...

Hi, The code @ line 584 of TargetRegistry.h effectively suppresses specifying any AsmStreamer constructor function but stock createAsmStreamer one. Is it by intention or condition should be replaced with != ? Best regards, Max

...ked? There should already be sufficient support for what you're trying to do. See MCOperand::CreateInst(). The concept is that you'll build a composite MCInst in your AsmPrinter::EmitInstruction() method, which uses Inst-type MCOperands to hold a list of sub-instructions. Then you call AsmStreamer::EmitInstruction() on the composite MCInst. --Owen

On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >>> >>> New method of emitting object code is ok for me. But it is still >>> experimental, isn't it? >> >> Yes. > > Thank you for answers! > > Now there is a way to implement what I'd like to. But it would be MUCH > better if LLVMTargetMachine::addPassesToEmitFile could take

...oo, as should long branch optimization. In fact the earliest pdp-11 unix compilers did long branch optimization in the assembler. Moving this to the assembler would require some community buy in. To do this in the assembler and not create any issues, I think you would need to serialize one the asmstreamer interfaces and have a way to edit the instruction stream parts. Then you could play it back through asm printer. Reed

...debug info, exception info, and inline asm. I plan to tackle the former two over the next couple weeks. For ARM, the ARM backend has completely migrated yet. The first major step is to get the ARM backend emitting instructions by lowering them to MCInst's then pushing the MCInst through the AsmStreamer interface. This allows the encoder to handle them, or (if actually emitting a .s file) the ARMInstPrinter to print out the instruction. I started this process, but haven't finished it and it isn't a very high priority for me. To see what is being emitted textually, you can do something li...

Hello all, We're developing an integrated assembler for a VLIW target, and some of the optimizing our assembler needs to do must be done on a per-packet basis. This requires us to be able to traverse instruction within a packet, and one particular optimization requires traversal of previous packets as well. We're considering adding support for MCInst bundles in the MC layer to

Hello, I'm interested in the status of LLVM-MC. My particular interest is in generating executables for ARM embedded applications. I assume this application is not terribly high on the priority list, so I would like to know how I can contribute. Can someone point me to some information and/or docs on the project and its status. Also, if someone could give me an example of how

Chris Lattner wrote: > On Mar 27, 2010, at 11:56 AM, Peter Shugalev wrote: > >>>> What exactly is expected to be coming? Will it be the same way MachO is >>>> currently implemented but with some flexibility to supply my own class >>>> to do actual object output? Or just a return of old ObjectCodeEmitter? >>> We're integrating a full assembler