similar to: [LLVMdev] print machine code using llvm c++ api

Hi, Can anyone please tell me how can I scalarize or de-vectorize the llvm vector ir. In this (http://old.nabble.com/Re%3A-Thoughts-about-the-llvm-architecture---p2961720 3.html) thread I found LegalizeTypes will do this while generating machine code from llvm ir.. How do I convert llvm ir to selection Dag. And scalarize the vector ir and again get back llvm ir. Thanks &

Hi, I would like your opinions on the contract we have between the LLVM IR and the backends. * Context * Right now, the backends are supposed to be able to perform instruction selection on any valid LLVM IR. Although this is *not* something I want to change for GlobalISel, I thought I brought that up on the mailing list to discuss the implications. In particular, in the past, some people

Hello, Please, I need more information on the runtime optimizer used in the LLVM JIT. - Where can I find it in the LLVM source code? - Are those runtime optimizations done on the LLVM representation code or on the machine code? Sara -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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

Thanks Evan. On 09/11/2007, at 6:50 PM, Evan Cheng wrote: >> 1. What optimization passes, if any, should I run on the module >> before I pass it to the ExecutionEngine. > > The default JIt driver, lli, runs everything. My reading of the lli source indicates that it's not explicitly doing any opt passes - is that happening implicitly in the ExecutionEngine? I can see

Hi! I'm looking for a way to make the the "llc" tool (or any other tool), directly produce a binary file for some target. The TargetMachine class has a method 'addPassesToEmitMachineCode', that's suitable for that, but that method also requires an instance of MachineCodeEmitter. The existing MachineCodeEmitter derived classes are either debug-only (writing to

Hi all, I can't find a way to add a MachineFunctionPass to the common codegen passes (LLVMTargetMachine::addPassesToEmitMachineCode) while JITting (the pass manager is associated with the jitstate of the JIT and I can't access it because it's private). Have I missed something? Or adding a MachineFunctionPass to codegen requires to change the

Chris Lattner wrote: >> The TargetMachine class has a method 'addPassesToEmitMachineCode', that's >> suitable for that, but that method also requires an instance of >> MachineCodeEmitter. > > Actually, you probably want to plug into the addPassesToEmitFile API, when > FileType is set to ObjectFile. X86TargetMachine::addPassesToEmitFile > demonstrates

On Mon, 27 Feb 2006, Vladimir Prus wrote: > I'm looking for a way to make the the "llc" tool (or any other tool), > directly produce a binary file for some target. ok > The TargetMachine class has a method 'addPassesToEmitMachineCode', that's > suitable for that, but that method also requires an instance of > MachineCodeEmitter. Actually, you probably

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

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

I am creating an ExecutionEngine using the LLVMCreateExecutionEngineForModule function from the C API. I am get a set fault with the following backtrace. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000120 0x0000000107c06643 in llvm::LLVMTargetMachine::addCommonCodeGenPasses () (gdb) bt #0 0x0000000107c06643 in

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

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

> On Jan 22, 2016, at 4:10 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- > >> From: "Quentin Colombet via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >> To: "Matthias Braun" <matze at braunis.de <mailto:matze at braunis.de>> >> Cc: "llvm-dev"

Hi, Why are there so many undocumented (and as I far I can see) unnecessary API changes? Recently there has been: 1. For JIT applications, please include llvm/Target/TargetSelect.h and call the llvm::InitializeNativeTarget() function before creating an EE. 2. The major CHANGE is: the JIT will no longer be safe for executing threaded applications without first invoking

Hi, Just realized that ability to generate static object code (e.g. ELF w/o using JIT) is no longer available in 2.7 (at least in release_27 branch). For example > llc -filetype=obj whatever.bc doesn't work in Linux environment anymore (well it wasn't fully implemented before but it worked for simple bytecodes in 2.6). I used to generate code by creating TargetMachine and

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