search for: debugbuild

...591cffa/attachment.obj> -------------- next part -------------- #0 0x9004802c in kill () #1 0x9012dfb4 in abort () #2 0x94b2d0b0 in __eprintf () #3 0x00074cd4 in llvm::PPCJITInfo::relocate (this=0x0, Function=0x8088004, MR=0x6604b30, NumRelocs=1, GOTBase=0x0) at /Users/andreas/build/llvm-1.8/debugBuild/../llvm/lib/Target/PowerPC/PPCJITInfo.cpp:205 #4 0x00017c00 in (anonymous namespace)::JITEmitter::finishFunction (this=0x6602f80, F=@0x6604db0) at /Users/andreas/build/llvm-1.8/debugBuild/../llvm/lib/ExecutionEngine/JIT/JITEmitter.cpp:824 #5 0x0005a984 in (anonymous namespace)::PPCCodeEmitter::ru...

...f() and alignmentof() first-class operations in the IR would have the advantage of making the generated IR clearer; And we already know that it can be done because the tricks exist. A lot of this thinking comes out of my attempting to create (as I mentioned on the other thread) a generic "DebugBuilder", similar to IRBuilder, that pumps out source level debugging definitions. As much as possible, I want to hide details of the target machine from the user of the API. You ought to be able to hand it an LLVM type, plus a little sprinkling of source-derived metadata to go along with it, an...

...m::Value*, llvm::Value*, llvm::Value*, llvm::DataLayout const&, llvm::TargetLibraryInfo const*, llvm::DominatorTree const*, llvm::AssumptionCache*, llvm::Instruction const*) /scratch/1/ismail/llvm-upstream/lib/Analysis/InstructionSimplify.cpp:3528:0 ...snip... Stack dump: 0. Program arguments: debugbuild/bin/opt -instcombine -licm -simplifycfg -instcombine -loop-rotate -loop-vectorize -instcombine 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'Combine redundant instructions' on function '@strsave' --- Looking at the code, the...

...t const&, >> llvm::TargetLibraryInfo const*, llvm::DominatorTree const*, >> llvm::AssumptionCache*, llvm::Instruction const*) >> /scratch/1/ismail/llvm-upstream/lib/Analysis/InstructionSimplify.cpp:3528:0 >> ...snip... >> Stack dump: >> 0. Program arguments: debugbuild/bin/opt -instcombine -licm -simplifycfg >> -instcombine -loop-rotate -loop-vectorize -instcombine >> 1. Running pass 'Function Pass Manager' on module '<stdin>'. >> 2. Running pass 'Combine redundant instructions' on function '@strsave' >...

...t;> const*, llvm::DominatorTree const*, llvm::AssumptionCache*, >>>> llvm::Instruction const*) >>>> /scratch/1/ismail/llvm-upstream/lib/Analysis/InstructionSimplify.cpp:3528:0 >>>> ...snip... >>>> Stack dump: >>>> 0. Program arguments: debugbuild/bin/opt -instcombine -licm >>>> -simplifycfg -instcombine -loop-rotate -loop-vectorize -instcombine >>>> 1. Running pass 'Function Pass Manager' on module '<stdin>'. >>>> 2. Running pass 'Combine redundant instructions' on function...

...> >>>> llvm::Instruction const*) >> >>>> >> >>>> /scratch/1/ismail/llvm-upstream/lib/Analysis/InstructionSimplify.cpp:3528:0 >> >>>> ...snip... >> >>>> Stack dump: >> >>>> 0. Program arguments: debugbuild/bin/opt -instcombine -licm >> >>>> -simplifycfg -instcombine -loop-rotate -loop-vectorize -instcombine >> >>>> 1. Running pass 'Function Pass Manager' on module '<stdin>'. >> >>>> 2. Running pass 'Combine redundant in...

On May 22, 2008, at 6:40 PM, Talin wrote: >> LLVM already does this. >> >> http://www.nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt >> >> — Gordon >> > Is there a similar technique that would allow calculation of the > alignment? (which is also required by the DWARF derived-type > descriptor.) There is more than one form of

Gordon Henriksen wrote: > On 2008-05-21, at 22:17, Talin wrote: > >> As I understand this, this issue and others like it all require a >> difficult step to be taken, which is to introduce the concept of a >> constant whose value is not known until code generation time or at >> least >> until the compilation target is fully known. These "late bound

...; llvm::Instruction const*) >>> >>>> >>> >>>> /scratch/1/ismail/llvm-upstream/lib/Analysis/InstructionSimplify.cpp:3528:0 >>> >>>> ...snip... >>> >>>> Stack dump: >>> >>>> 0. Program arguments: debugbuild/bin/opt -instcombine -licm >>> >>>> -simplifycfg -instcombine -loop-rotate -loop-vectorize -instcombine >>> >>>> 1. Running pass 'Function Pass Manager' on module '<stdin>'. >>> >>>> 2. Running pass 'Combine...

...t; >>> >>>> > >>> >>>> > /scratch/1/ismail/llvm-upstream/lib/Analysis/InstructionSimplify.cpp:3528:0 > >>> >>>> ...snip... > >>> >>>> Stack dump: > >>> >>>> 0. Program arguments: debugbuild/bin/opt -instcombine -licm > >>> >>>> -simplifycfg -instcombine -loop-rotate -loop-vectorize > -instcombine > >>> >>>> 1. Running pass 'Function Pass Manager' on module '<stdin>'. > >>> >>>> 2. Runnin...

...ode is too far off. When I run my program outside of gdb, the native function is more than 2^23 words from the JIT code, which is too far for a PC relative jump: nativeFunction address 0x63b4d4c JIT memory base 0x9008000 (allocated in JITMemoryManager constructor) /Users/andreas/build/llvm-1.8/debugBuild/../llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of range!"' And when I run the same program from gdb, I get lucky and the native function is less than 2^23 words fro...

...purely as a symbolic, opaque object, while the code generator simply converts it into a ConstantInt. This makes filling in the dwarf debugging structures relatively easy as long as you have an LLVM type reference to use as a measuring stick. In fact, I'd likely make the hypothetical "DebugBuilder" API such that most of the info was derived from an LLVM type given as a parameter, with just a few additional parameters to specify the things that cannot be determined just from looking at the the LLVM type. -- Talin

On Wed, 21 May 2008, Talin wrote: > On a related topic: The source-level debugging descriptors require you > to know up front what the sizeof pointer types are. Is there any hope of > the frontend remaining blissfully unaware of platform details? I really don't know how to do this. The current debug info stuff depends on emitting size info into the IR. At this point, I don't

On a related topic: The source-level debugging descriptors require you to know up front what the sizeof pointer types are. Is there any hope of the frontend remaining blissfully unaware of platform details? Chris Lattner wrote: > On May 6, 2008, at 11:12 PM, Talin wrote: > > >> For the most part, it appears that writing a front end can be almost >> entirely