search for: machinemoduleinfo

Hi Evan, >>Is it possible to implement it without using MachineModuleInfo? but llvm-2.5 didn't , if implement it without using MachineModuleInfo, so I should create another ADT, but that is mostly same to MachineModuleInfo, that's repeat work! or less cost for me ! >> It's being removed. if so, what's the replacement of the MachineModuleInfo ?...

Hi, I run into a a strange error when compiling with debug infos, where LLC tries to generate a variable DIE using a completely wrong frame-index (DebugDwarf tries to resolve frame index 27 in a simple function which only has a single frame object .. ). After digging around, I found that MachineModuleInfo has a VariableDbgInfo map, that is filled by SelectionDAGBuilder. MMI->VariableDbgInfo maps MDNodes representing variables to a <FrameIndex, DebugLoc> pair. All infos of all functions reside in a single map per module. In lib/CodeGen/StackColoring.cpp:493 is the only place where this...

...t; + > +#include "llvm/Support/DataTypes.h" > +#include <string> > +#include <vector> > + > +namespace llvm { > + > +class Function; > +class MachineCodeEmitter; > +class TargetData; > +class TargetMachine; > +class MachineFunction; > +class MachineModuleInfo; > +class MachineMove; > +class MRegisterInfo; > + > +class DwarfEmitter { > +protected: > + /// BufferBegin/BufferEnd - Pointers to the start and end of the > memory > + /// allocated for this code buffer. > + unsigned char *BufferBegin, *BufferEnd; > + > + /...

...===================================== > --- include/llvm/CodeGen/MachineCodeEmitter.h (revision 46612) > +++ include/llvm/CodeGen/MachineCodeEmitter.h (working copy) > @@ -26,6 +26,7 @@ > class MachineConstantPool; > class MachineJumpTableInfo; > class MachineFunction; > +class MachineModuleInfo; > class MachineRelocation; > class Value; > class GlobalValue; > @@ -136,6 +137,72 @@ > CurBufferPtr = BufferEnd; > } > > + > + /// emitULEB128Bytes - This callback is invoked when a ULEB128 > needs to be > + /// written to the output stream. > + vo...

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL:

...ypes.h" >> +#include <string> >> +#include <vector> >> + >> +namespace llvm { >> + >> +class Function; >> +class MachineCodeEmitter; >> +class TargetData; >> +class TargetMachine; >> +class MachineFunction; >> +class MachineModuleInfo; >> +class MachineMove; >> +class MRegisterInfo; >> + >> +class DwarfEmitter { >> +protected: >> + /// BufferBegin/BufferEnd - Pointers to the start and end of the >> memory >> + /// allocated for this code buffer. >> + unsigned char *Buffe...

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

...AssignableConcept<llvm::MachineMove>': c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/stl_vector.h: 179: insta ntiated from 'std::vector<llvm::MachineMove, std::allocator<llvm::MachineMove> > ' c:/Users/Greybird/Desktop/llvm/llvm-2.4/include/llvm/CodeGen/ MachineModuleInfo.h :1007: instantiated from here c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ boost_concept_check.h:216 : error: '__gnu_cxx::_SGIAssignableConcept<_Tp>::__a' has incomplete type c:/Users/Greybird/Desktop/llvm/llvm-2.4/include/llvm/CodeGen/ MachineModuleInfo.h :53: erro...

...gt; I run into a a strange error when compiling with debug infos, where LLC tries to generate a variable DIE using a completely wrong frame-index (DebugDwarf tries to resolve frame index 27 in a simple function which only has a single frame object .. ). > > After digging around, I found that MachineModuleInfo has a VariableDbgInfo map, that is filled by SelectionDAGBuilder. > MMI->VariableDbgInfo maps MDNodes representing variables to a <FrameIndex, DebugLoc> pair. All infos of all functions reside in a single map per module. > > In lib/CodeGen/StackColoring.cpp:493 is the only place...

Mark Kromis wrote: > Resend > > > On Oct 14, 2008, at 5:40 AM, Mark Kromis wrote: > > >> Greetings, >> >> I have a compiler error that I have not been able to get through. I >> usually depend upon pre-built binaries but there was none available >> for the pre-release. I also try scanning the web site and mail list >> but was unable to

...>> The headers that I am including in my .cpp file are: >> >> #include <llvm/DerivedTypes.h> >> #include <llvm/Constants.h> >> #include <llvm/GlobalVariable.h> >> #include <llvm/Module.h> >> #include <llvm/CodeGen/MachineModuleInfo.h> >> #include <llvm/Support/Dwarf.h> >> #include <llvm/System/Path.h> >> > > There's your problem. > > >> Any ideas? Am I going to have to put my .cpp file in some library other >> than Support? >> > > If y...

...sis that created it. this happens for instance when you schedule a module pass (where you could operate on the global control-flow) somewhere during code generation. A workaround could be to modify the MachineFunctionAnalysis such that it stores the MachineFunction in a look-up table inside the MachineModuleInfo instead of destroying it before your module pass is run. once your module pass is finished, a new MachineFunctionAnalysis is scheduled by the pass manager. Now, instead of creating a new function, you could check the look-up table of the MachineModuleInfo to get the original MachineFunction. i...

CodeGen, since it depends on MachineModuleInfo. On 2008-06-05, at 04:06, Talin wrote: > HyperQuantum wrote: >> I'm not a LLVM developer, but I'll give it a try... >> >> On Wed, Jun 4, 2008 at 9:12 AM, Talin <viridia at gmail.com> wrote: >> >> >>> I went and added a new file to the "...

Hi all, I am trying to build a global control flow graph at machine code level. Essentially, I need the handles to the MachineFunction's corresponding to every call site inside a MachineFunction in order to get the handles to MachineBasicBlock's with return statements inside the callee. Currently, the codegen module processes one MachineFunction at a time and hence I can't find a way

Dear LLVM, I'm trying to understand why opt tool does not know some of the registered passes, for example, -targetpassconfig, -gc-lowering, -unreachableblockelim, -unreachableblockelim, -stack-protector, -machinemoduleinfo. This prevents me from using bugpoint to reduce the crash in backend. As I understand, they should be registered and available through the command line in the same way as all other passes, shouldn't they? Thanks, - Dima.

...on attributes are > available) > Only if TargetContext and SubtargetContext are abstract interfaces with trivial implementations available for cases where there is no target (in the libTarget sense). I don't really think that's what you're aiming for, so I would advocate for the MachineModuleInfo or the TargetMachine being the provider of the CGContext or the TargetContext and SubtargetContext. I like the TargetMachine providing it personally, but I don't feel strongly here. I also think that we could start with the MachineModuleInfo providing it and refactor that in a subsequent patch....

...6/29 Duncan Sands <baldrick at free.fr>: > Hi Dima, > >> I'm trying to understand why opt tool does not know some of the >> registered passes, for example, -targetpassconfig, -gc-lowering, >> -unreachableblockelim, -unreachableblockelim, -stack-protector, >> -machinemoduleinfo. This prevents me from using bugpoint to reduce the >> crash in backend. As I understand, they should be registered and >> available through the command line in the same way as all other >> passes, shouldn't they? > > these are codegen passes not IR passes, and thus are...

...00007fa91cc3baf0 abort + 272 5 libc.so.6 0x00007fa91cc332df __assert_fail + 239 6 llc 0x0000000000ebfdad 7 llc 0x0000000000ebffa6 8 llc 0x0000000000ec2f7b 9 llc 0x0000000000eb95e0 llvm::DwarfWriter::BeginModule(llvm::Module*, llvm::MachineModuleInfo*, llvm::raw_ostream&, llvm::AsmPrinter*, llvm::TargetAsmInfo const*) + 166 10 llc 0x0000000000b9b513 11 llc 0x0000000001142c73 llvm::FPPassManager::doInitialization(llvm::Module&) + 65 12 llc 0x0000000001142d96 llvm::FunctionPassManagerImpl::doIn...

...- MachineBlockPlacement - MachineBranchProbabilityInfo - MachineCodeEmitter - MachineCopyPropagation - MachineCSE - MachineDominators - MachineFunctionAnalysis - MachineFunction - MachineFunctionPass - MachineFunctionPrinterPass - MachineInstrBundle - MachineInstr - MachineLICM - MachineLoopInfo - MachineModuleInfo - MachineModuleInfoImpls - MachinePassRegistry - MachinePostDominators - MachineRegisterInfo - MachineScheduler - MachineSink - MachineSSAUpdater - MachineTraceMetrics - MachineVerifier Are there any files in this list that should not be moved? Any others that should be added? Any suggestions on w...

...ences my header, so I'm not sure where the cycle is. The headers that I am including in my .cpp file are: #include <llvm/DerivedTypes.h> #include <llvm/Constants.h> #include <llvm/GlobalVariable.h> #include <llvm/Module.h> #include <llvm/CodeGen/MachineModuleInfo.h> #include <llvm/Support/Dwarf.h> #include <llvm/System/Path.h> My .h file uses forward declarations for everything and needs no headers (yet). I need MachineMouleInfo.h to get LLVMDebugVersion, and I use Path to split the module directory name from the file name. Any i...