similar to: [LLVMdev] how to stream output of addPassesToEmitMC

On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > New patch taking Eli's comments into account. Comments inline. If you have commit access, I'd fire away. If not, I can. diff --git include/llvm/MC/MCAssembler.h include/llvm/MC/MCAssembler.h index 07ca070..afff96e 100644 --- include/llvm/MC/MCAssembler.h +++ include/llvm/MC/MCAssembler.h

New patch. Thanks for all of your comments ! > Comments inline. If you have commit access, I'd fire away. If not, I can. I don't have commit access, if you find it ok, please commit it. :) Olivier. On Wed, Jul 21, 2010 at 6:56 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant > <meurant.olivier at gmail.com>

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

New patch taking Eli's comments into account. Olivier. On Tue, Jul 20, 2010 at 11:09 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Jul 20, 2010 at 1:36 PM, Olivier Meurant > <meurant.olivier at gmail.com> wrote: >>> Seems reasonable, but I haven't looked at the code yet. I would >>> suggest trying to split your work up into separate

Hi, I am working on an LLVM backend for GPUs, and I would like to be able to emit a very simple byte stream of machine code, so that it can be fed directly into the GPU. I don't need anything fancy, just the raw machine code, one instruction after another. I think I've already implemented everything in the backend that is required to do this, but I'm not sure how to get a pointer to

Dear David, Dumb question: Would it be easier to write an LLVM tool that took the large IR file and divided it into several smaller IR files that could then be code-generated separately? -- John T. David Greene wrote: > We process very large programs and it is not unusual for the IR for some > compilation unit to exceed system memory. With some hacking in LLVM 2.5 > I was able to

We process very large programs and it is not unusual for the IR for some compilation unit to exceed system memory. With some hacking in LLVM 2.5 I was able to coax LLVM to generate asm for each functioin as it was processed and then completely forget about it (i.e. delete it) and move on to the next function. This required a bit of hackery. I had to create two pass managers, one for the module

Some boring style comments: - whack trailing whitespace - spaces, not tabs - the methods in MCJITStreamer.cpp should probably have blank lines between them There seems to be an ownership problem of the MCJITObjectWriter. If I understand the code correctly, the assembler Finish method takes ownership of the Writer parameter, which presumably is needed to JIT two functions. +1 for separate

On 04/01/2013 12:31 PM, Chandler Carruth wrote: > On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com > <mailto:nrotem at apple.com>> wrote: > > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if > the attributes changed). Do you have another solution in mind ?

Together with Jan Sjodin (in copy of this email), we begin an implementation of the JIT with MC. The idea, suggested by Jan, is to develop a MCJIT in parallel of the current JIT and to keep the two implementations until (at least) the new MC one is mature enough. Currently code is kept on gitorious (http://gitorious.org/llvm-mc-jit/llvm-mc-jit). Following this, a boolean "bool MCJIT =

Dear LLVM, Might be a easy question for someone, but not for me now. Consider there is a TargetMachine instance. Having this target, how could you get a corresponding Mangler class instance? Mangler depends on MCContext, which is connected with LLVMTargetMachine inherited from TargetMachine. However, LLVMTargetMachine is only available for targets machines implementations, and not available

Hi, Sean: I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change to the IPO pass-ordering for now. However, when I make a minor change to populateLTOPassManager() by separating module-pass and non-module-passes, I saw quite a few performance difference, most of them are degradations. Attacking these degradations one by one in a piecemeal manner is wasting

Hi Jim, Thanks for reply. I'm sorry I didn't make myself clear enough. The MCInst created by MCDisassembler depends on the instructions defined in td files. These instructions do not have a one to one mapping to ARM instructions. There are usually one or more instructions defined in the td file correspond to one actual ARM instruction. Thanks, David On Thu, Jun 7, 2012 at 1:27 PM, Jim

That depends on how you define "one ARM instruction." It's not a clear cut thing. For example, is "add r1, r2, r3" the same ARM instruction as "add r1, r2, #4"? What is a distinct instruction and what's a variant encoding of the same instruction is often entirely a matter of convenience. -Jim On Jun 8, 2012, at 6:40 AM, Fan Dawei <fandawei.s at

> In the context of the JIT, there really is no such thing as a > relocation, just fixups. I'm not completely sure what the right > approach is, but the JIT should be able to fully resolve all of the > symbols that are being used in the module. We may need some extra > interfaces to allow the JIT to tell the MCAssembler about the address > of some external symbols though.

Hi everyone, I downloaded the latest version of LLVM PTX backend from http://www.prog.uni-saarland.de/projects/anysl and made the required changes to all the files mentioned in the README. But I get the following error when I compile it. llvm[3]: Compiling PTXBackend.cpp for Release build In file included from PTXBackend.h:70:0, from PTXBackend.cpp:36: PTXPasses.h: In constructor

> On Jan 22, 2016, at 3:17 PM, Matthias Braun <matze at braunis.de> wrote: > > >> On Jan 22, 2016, at 2:36 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I would like your opinions on the contract we have between the LLVM IR and the backends. >> >> >> * Context * >> >>

That sounds like a missed multi-threading issue with LLVM. I can't imagine why the user should be forced to serialize creation of MCContext objects. I would suggest filing a bug for this. A simple lock probably wouldn't be too detrimental to performance here, since MCContext objects shouldn't be created too often. On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at

Tom, I think it might be productive to fork this thread to discuss making the requirements for upstreaming a new LLVM target more explicit and open. I'd also like to gauge interest in an idea I've discussed privately with a few community members, namely the concept of having a semi-official "incubation" system whereby proposed backends could get a trial run before becoming part

Hello, I want to write a modulePass in addPreEmitPass() for NVPTX, but I encounter an assertion failed when executing clang. Here is my error message. ==== Pass 'NVPTX Assembly Printer' is not initialized. Verify if there is a pass dependency cycle. Required Passes: llc: /home/pyyu/local/llvm/lib/IR/PassManager.cpp:637: void llvm::PMTopLevelManager::schedulePass(llvm::Pass*): Assertion