search for: asmstreams

...in place to handle the extremely unlikely case of a static object constructor writing to one of the standard streams. 2. Slowness of std::cout and friends due to their reliance on FILE * buffering and resulting excessive virtual function calls. I just implemented "standard" AsmStreams (the name for my custom streams) to handle the cases where we want to dump Asm to standard error. I just point the AsmStreambuf to STDERR_FILENO. I simply avoid the constructor issue by declaring that no user shall write to an AsmStream in a static object constructor. So we don't have wo...

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

I checked recent revisions 138624 and 138620 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

Chris Lattner wrote: > 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

...dislike this strongly, but it isn't really related. > 2. Slowness of std::cout and friends due to their reliance on FILE * > buffering and resulting excessive virtual function calls. Use of FILE* is not the issue, virtual functions are. > I just implemented "standard" AsmStreams (the name for my custom streams) to > handle the cases where we want to dump Asm to standard error. I just point > the AsmStreambuf to STDERR_FILENO. I simply avoid the constructor issue by > declaring that no user shall write to an AsmStream in a static object > constructor. So we d...

On Mar 27, 2010, at 1:50 PM, Peter Shugalev wrote: > Chris Lattner wrote: >> 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

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 we need,

On Jan 21, 2014, at 3:20 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jan 21, 2014, at 2:20 PM, sebastien riou <matic at nimp.co.uk> wrote: > >> Hi, >> >> I would like to execute a MachineFunctionPass after all other passes >> which modify the machine code. >> In other words, if we call llc to generate assembly file, that pass >>

Hi ! > Sorry I missed responding to this email sooner. No problem, I was not in a hurry. :) > The approximate approach I had in mind sounds like what you describe, Ok Cool ! > I have been meaning to do this, but won't have time for a couple weeks I suspect. So I will give it a try. :) I was able to quickly hack a JITObjectWriter and I am able to execute simple functions (with

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, 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

Mario, On Nov 29, 2012, at 3:00 PM, Mario Guerra <mariog at codeaurora.org> wrote: > 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

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

On 10/15/2013 01:30 PM, Rafael Espíndola wrote: > On 14 October 2013 21:56, reed kotler <rkotler at mips.com> wrote: >> I would like to do constant pools over an entire module instead of just on a >> per function basis as constant islands does it now. >> >> It seems there are two options for this: >> >> 1) collect the machine functions with their

On Mar 5, 2010, at 3:20 PM, Wayne Anderson wrote: > 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

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