search for: llvmtargetmachine

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 /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/LLVMTarget...

...chitectures. I'm using the "--target" options to choose my set of instructions, and I would like to use the "-mcpu" to choose the architecture of which I want to compile the code. Does it seem right? But at the moment I cannot manage to have the CPU information in my "LLVMTargetMachine" constructor. I have it when I go through llc: clang -emit-llvm ... llc -mcpu=mycpu ... But not when I go directly from clang clang -mcpu=mycpu What should I do to have this information in the constructor using only the clang command? Best Regards, Romaric

The distinction between the LLVMTargetMachine and TargetMachine classes has become somewhat muddy recently. So I created: https://reviews.llvm.org/D38482 to clean things up. During review it was noted that we may rather merge the two instead which looks like this: https://reviews.llvm.org/D38489 <https://reviews.llvm.org/D38489> We r...

Currently, the MachO and ELF Writers and MachineCodeEmitters are hard-coded into LLVMTargetMachine and llc. In other words, the 'object file generation' capabilities of the Common Code Generator are not generic. LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the derived backend TargetMachine implements one of getMachOWriterInfo or getELFWriterInfo, and returns a corre...

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi > Amini via llvm-dev > Sent: Friday, January 06, 2017 11:10 AM > To: Sumanth Gundapaneni > Cc: LLVM Developers > Subject: Re: [llvm-dev] LLVMTargetMachine with optimization level passed > from clang. > > > > On Jan 6, 2017, at 10:56 AM, Sumanth Gundapaneni > <sgundapa at codeaurora.org> wrote: > > > > Here is a problem scenario. > > > > I want to enable a backend pass at -O2 or above. > > if (TM...

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

On Tue, Oct 3, 2017 at 8:54 AM Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 10/02/2017 10:57 PM, Matthias Braun via llvm-dev wrote: > > The distinction between the LLVMTargetMachine and TargetMachine classes > has become somewhat muddy recently. So I created: > > https://reviews.llvm.org/D38482 > > to clean things up. During review it was noted that we may rather merge > the two instead which looks like this: > > https://reviews.llvm.org/D38489 > &gt...

...ating 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 llvm::LLVMTargetMachine::addCommonCodeGenPasses () #1 0x0000000107c05c6b in llvm::LLVMTargetMachine::addPassesToEmitMachineCode () #2 0x0000000107ead7ab in llvm::JIT::JIT () #3 0x0000000107eaac21 in llvm::JIT::createJIT () #4 0x00000...

...rom: vtable for llvm::EBCRegisterInfoin libLLVMEBCCodeGen.a(EBCRegisterInfo.cpp.o) vtable for llvm::EBCGenRegisterInfoin libLLVMEBCCodeGen.a(EBCRegisterInfo.cpp.o) "llvm::TargetMachine::getAsmVerbosityDefault()", referenced from: getVerboseAsm() in libLLVMCodeGen.a(LLVMTargetMachine.cpp.o) "llvm::TargetData::getPrefTypeAlignment(llvm::Type const*) const", referenced from: llvm::SelectionDAG::getConstantPool(llvm::MachineConstantPoolValue*, llvm::EVT, unsigned int, int, bool, unsigned char)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o) llvm::SelectionDAG::...

...thing on it. I also recall seeing comments here that it's due for a rewrite from scratch, and that various people were looking into it. Can anyone go into more detail as to what exactly is wrong with the C backend, and whether this rewrite is happening? The other thing I could do is to use the LLVMTargetMachine and treat my HLL as a low-level machine; this gets me a certain amount of good stuff like register allocation and more optimisations, but the documentation is still pretty basic (e.g. http://wiki.llvm.org/Absolute_Minimum_Backend is three short paragraphs) and I'm not certain as to whether LLVM...

> Currently, the MachO and ELF Writers and MachineCodeEmitters are > hard-coded into LLVMTargetMachine and llc. I am also interested in working on this area and interested in writting a COFF file backend. > In other words, the 'object file generation' capabilities of the > Common Code Generator are not generic. I was looking at making a parallel class to MachineCodeEmitter, 'M...

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

...d then be simply re-written to use these generic functions instead of the hard-coded MachO and ELF ones. On Sun, Mar 15, 2009 at 10:39 PM, Aaron Gray <aaronngray.lists at googlemail.com> wrote: >> Currently, the MachO and ELF Writers and MachineCodeEmitters are >> hard-coded into LLVMTargetMachine and llc. > > I am also interested in working on this area and interested in writting a > COFF file backend. > >> In other words, the 'object file generation' capabilities of the >> Common Code Generator are not generic. > > I was looking at making a parallel cl...

...nth G -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Friday, January 6, 2017 12:37 PM To: Sumanth Gundapaneni <sgundapa at codeaurora.org> Cc: jpaquette at apple.com; LLVM Developers <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] LLVMTargetMachine with optimization level passed from clang. > On Jan 6, 2017, at 7:59 AM, Sumanth Gundapaneni via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > getOptLevel() gets the level from TargetMachine which is created by > the Backendutil in clang with either "Default", &qu...

...l seeing comments here that it's due > for a rewrite from scratch, and that various people were looking into > it. Can anyone go into more detail as to what exactly is wrong with the > C backend, and whether this rewrite is happening? > > The other thing I could do is to use the LLVMTargetMachine and treat my > HLL as a low-level machine; this gets me a certain amount of good stuff > like register allocation and more optimisations, but the documentation > is still pretty basic (e.g. > http://wiki.llvm.org/Absolute_Minimum_Backend is three short paragraphs) > and I'm not c...

...th CodeGenOpt::Default. I am available on IRC @ sgundapa. -----Original Message----- From: jpaquette at apple.com [mailto:jpaquette at apple.com] Sent: Thursday, January 5, 2017 12:24 PM To: sgundapa at codeaurora.org Cc: LLVM Developers <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] LLVMTargetMachine with optimization level passed from clang. Most of the stuff you’re looking for lives in TargetPassConfig.cpp. There are a few examples of how you might do it that live in there too. What it comes down to is finding the place you want your pass to live and sticking in some logic like this in ther...

Aaron, I mailed in the same mail twice (by mistake), you answered both copies. Differently! In any case, I've re-read what exists. I'm dumping what I understand here, so that we can discuss in detail. I'm using MachO as the example object format, as the ELF code is totally broken and outdated. Lets use the following as the basis for our discussion? There are 3 classes which

...ote: > >>>> 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 arbitrary >> MCStreamer as input. Without such a feature when compiling bytecode >> (i.e. emulating llc -filetype=obj behaviour) I have to emit .s file >> first, disassemble it and feed to custom MCStreamer. That'll hopely work >> but it...

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 LLVMTargetMachine::addPassesToEmitMachineCode f...

...he old one. Then clients don't > need to change, and we can keep the old one available for a little > while if we want, for testing. I am not a big fan of renaming - it can easily cause confusion. Besides, fast-alloc goes with fast-isel. But perhaps we could take this opportunity to let LLVMTargetMachine choose a register allocator based on the optimization level? It is already enabling fast-isel that way, and -O0 -regalloc=linearscan (which is the default) doesn't really make sense. LLVMTargetMachine::addCommonCodeGenPasses does a decent job of building a codegen pipeline, except it needs hel...