similar to: [LLVMdev] Wiki to HTML docs - take 2

Seems the last use of DIFactory in LLVM/Clang is in: clang/lib/CodeGen/CGDebugInfo.cpp to get the enums llvm::DIFactory::OpDeref and llvm::DIFactory::OpPlus. Shouldn't this be moved to DIBuilder and remove the dependency completely? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

Thank you very much for you help, Renato! I read through paper you referred and also this document - http://llvm.org/docs/tutorial/JITTutorial1.html Following these instructions to create successful function I run into some problems: 1) llvm::getGlobalContext() does not exists anymore? "llvm/LLVMContext.h" too? 2) creating instance of IRBuilder don't require template (from tutorial

> Inline the init function: store 11 at the address of the "value" variable, > call printf with the string from r5. This is a bug, should have stored at an > offset of four (str r1, [r4,4]). Exactly! The IR is correct, the bug seems to be lower down. I'm no expert in the ARM back-end, though. But your report is detailed enough to help whoever is. ;) cheers, --renato

On 21 September 2010 17:48, Devang Patel <dpatel at apple.com> wrote: > In the combined llvm IR, @p3 and @p won't match as expected. Hi Devang, That's not quite what I was thinking... Maybe I explained badly... Imagine this: -- a.ll -- %struct.x = type { i32, i32 } %a = call void @func (%struct.x %b) -- b.ll -- %struct.y = type { i32, i32 } declare i32 @func (%struct.y)

On Sun, Sep 26, 2010 at 11:27 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2010 18:56, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > The syntax for the invoke instruction is a little misleading. %x is a > value > > that is being generated by the instruction, not passed to is. It is no > > different in that regard as to

On 27 April 2010 08:18, Stefano Delli Ponti <stefano.delliponti at gmail.com> wrote: > FYI > http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1 For Apache and Dhrystone, the performance boost is good (but only the former is really important), but for the rest, especially those with image/sound processing, and HMMR, it's still far behind. Is this only

http://llvm.org/docs/SourceLevelDebugging.html#ccxx_compile_units !1 = metadata !{ i32 524329, ;; Tag metadata !"MySource.cpp", metadata !"/Users/mine/sources", metadata !3 ;; Compile unit } !2 is the Compile Unit, right? !3 is also wrong. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at

Hello, Erik > Otherwise, I'd like to know what needs to be done to get unions > back in LLVM. Well, the answer is pretty easy: someone should "fix" them to be supported throughout the whole set of libraries and became a "maintainer". Otherwise the feature being unused will quickly became broken. -- With best regards, Anton Korobeynikov Faculty of Mathematics and

On 21 September 2010 18:39, Andrew Lenharth <andrewl at lenharth.org> wrote: > Type names don't have meaning.  If you want this not to happen, you > can generate a different opaque type for each type in your language to > prevent merging. Hi Andrew, Why create opaque types to avoid something that should be taken from granted (in a said "type-safe" representation)? I

On 26 September 2010 20:13, Nathan Jeffords <blunted2night at gmail.com> wrote: > I believe the perceived problem with using eh.exception is that > is disassociates the source of the value with the invoke instruction that > generated it. As far as reusing the landing pad, that is still possible, it > would just require a phi node in the landing pad to bring all the different >

Hello, I have a simple question. How to create "dummy" function which will have no functionality behind (return nothing and do nothing)? Currently I'm trying to do this: llvm::Constant* c = Module.getOrInsertFunction("dummy", FunctionThatNeedsToBeReplaced.getFunctionType()); llvm::Function* dummy = llvm::cast<llvm::Function>(c); This way I create new function that

On 10 September 2010 04:47, Liu <proljc at gmail.com> wrote: > trying this: > clang -march=armv7-a -mcpu=cortex-a9 -ccc-host-triple > arm-none-linux -ccc-gcc-name arm-none-linux-gnueabi-gcc a.c Hi Liu, That doesn't work for me. $ clang -march=armv7-a -mcpu=cortex-a9 -ccc-host-triple arm-none-linux -ccc-gcc-name arm-none-linux-gnueabi-gcc alias.c clang: warning: unknown

Here's a suggestion - can we make the "union patch" (the inverse of the patch that removed unions) as a downloadable file so that people who are interested in finishing the work can do so? On Tue, Sep 7, 2010 at 7:55 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 7 September 2010 15:36, Anton Korobeynikov <anton at korobeynikov.info> > wrote: > >

On Sun, Sep 26, 2010 at 1:44 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2010 20:13, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > I believe the perceived problem with using eh.exception is that > > is disassociates the source of the value with the invoke instruction that > > generated it. As far as reusing the landing pad,

On Aug 31, 2010, at 2:15 AM, Renato Golin wrote: > On 26 August 2010 09:32, Krister Wombell <kuwerty at gmail.com> wrote: >> I've also been looking at debugging with ELF and noticed the same problem as >> Renato. I just sent a patch to llvmcommits that fixes the problem. >> DW_at_stmt_list needs to emit a label(and therefore a relocation) for the >> offset

On Fri, Jun 17, 2011 at 12:04 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 17 June 2011 08:55, Kostya Serebryany <kcc at google.com> wrote: > > I am rather reluctant to add 'generic' code that handles unknown/untested > > platforms because the memory mapping is very platform specific anyway. > > Indeed, but the point of that is more for helping

FYI http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1

On 17 June 2011 09:14, Kostya Serebryany <kcc at google.com> wrote: > Maybe the fallback code should just use a function call. Much simpler for > documentation purposes. Sounds good. On 32-bit, the shadow region is: > [0x28000000, 0x3fffffff] HighShadow [0x24000000, 0x27ffffff] ShadowGap [0x20000000, > 0x23ffffff] LowShadow > > This is 0.5G total. So, I mmap all these

I was reading this page: http://llvm.org/docs/Passes.html and there seems to be lots of passes that depend on others to produce consistent non-redundant code. For instance, the DIE must run after Simple constant propagation, Loop-Closed SSA Form Pass is mostly (only) useful for other passes, such as LoopUnswitching, and a few passes that leave a good mess, requiring other passes to run

On Tue, Sep 7, 2010 at 1:56 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 6 September 2010 01:05, Talin <viridia at gmail.com> wrote: > > DISubprogram CodeGenerator::genDISubprogram(const FunctionDefn * fn, > (...) > > false /* isDefinition */, > (...) > > Hi Talin, > > The only difference from what I'm doing is that I only