similar to: [LLVMdev] Null pointers

On Mar 4, 2010, at 8:20 AM, Renato Golin wrote: > I'm recurrently falling into two null pointers when building some LLVM > objects: raw_fd_ostream and Twine. On both ctors, the char* is never > asserted to point somewhere. > > I know I have to make sure the string exists, but would be good to get > an assert instead of a segfault. It'd reduce debugging time a lot on

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

Hi all, I spend the last two weeks looking for solutions to print HTML files out of the wiki format. I tried to create a Perl hack (wasn't generic enough), a C++ parser/printer (would take too long) and looked into Deplate and some Wikimedia specific tools to convert to docbook, pdf and HTML. The last one was the most successful one (printed a nice PDF) but the XHTML was no good for Chrome

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

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)

I didn't know DIFactory existed until you mentioned it just now. And if folks are adding brand new classes to LLVM, can we not follow the naming conventions in the developer guidelines? On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at systemcall.org>wrote: > Seems the last use of DIFactory in LLVM/Clang is in: > > clang/lib/CodeGen/CGDebugInfo.cpp to get the enums

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

On 7 September 2010 15:36, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Otherwise the feature being unused will quickly became broken. It was already broken for ages... :/ Even if you're not using the backends (or MC), having it in front-end only will only confuse new users that will try to use it and hope it just works (my case, a few months ago). If there is nothing,

On 26 September 2010 22:11, Nathan Jeffords <blunted2night at gmail.com> wrote: > The "exception" value will *always* be i8*, it is not possible for it to be > anything different. > In the end, this a minor parser detail and it is not terribly important to > me one way or the other. I know, it is rather silly. It has more to do with debugging front-end code than

Ok, I see it. Works for me. On Sun, Sep 26, 2010 at 3:01 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2010 22:11, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > The "exception" value will *always* be i8*, it is not possible for it to > be > > anything different. > > In the end, this a minor parser detail and it

On 27 September 2010 01:12, Nathan Jeffords <blunted2night at gmail.com> wrote: > How about this syntax: > invoke @method(i32 %arg) >   ret i32 %return_value to label %success_branch > unwind i8* %exception_pointer to label %error_branch > this makes the instruction self consistent, and self documenting I like it. What if the function returns void? Would you omit the whole

When compiling LLVM on my Intel(R) Core(TM)2 Duo CPU P7450 running Ubuntu (gcc 4.4.5), I get this warning: /home/rengolin/workspace/llvm/rw/build/Release+Asserts/lib/libLLVMARMAsmParser.a(ARMAsmParser.o): In function `(anonymous namespace)::ARMAsmParser::ParseRegisterList(llvm::SmallVectorImpl<llvm::MCParsedAsmOperand*>&)': ARMAsmParser.cpp:(.text+0x4a05): warning: memset used with

2009/11/5 Oleg Knut <oleg77 at gmail.com>: > 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()); >

On Tue, Sep 21, 2010 at 12:27 PM, Renato Golin <rengolin at systemcall.org> wrote: > 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 -- >

This is a nominative vs. structural type system issue. You assume the type system to be nominative, while LLVM uses a structural one. In this type system Foo and Bar is the same type. There are various pros and cons for both systems. For LLVM it seems appropriate to use structural typing as it only uses types to calculate sizes, offsets and alignments. Btw arguably this is not a type safety

On 26 April 2010 10:49, Chandler Carruth <chandlerc at google.com> wrote: > Certainly for languages such as Java, they will make up a surprisingly large > chunk of the loads and stores, and instructions have much mor flexibility in > terms of syntax. On the flip side, it's a lot of plumbing IIRC, and we'd > really need to stick to the very minimal set of operations,

Hi all, I've sent it as a reply to another thread, but it was ill placed. Anyway, sorry about the duplication, but here it goes. I've been looking into the loop passes and noticed we do alias analysis and scalar evolution only, trying to clean up the loop as far as possible. I suppose that, if we were to define SCCs, split them into groups and re-arranging into multiple loops, we would

On 12/16/09 1:41 AM, Renato Golin wrote: > 2009/12/16 Talin<viridia at gmail.com>: > >> So, suppose I wanted to create an Eclipse plugin that could read an LLVM >> bitcode file. What would be the best way to bridge between the Java and C++ >> worlds? I thought about calling llvm-dis as a subprocess and then parsing >> the output, but that seems fragile to

Thanks for confirming this. Is there anybody with experience with ARM JIT codegen who can take a look into this? Or can somebody direct where to look how JIT on ARM processes getelementptr instruction? -- Martins Mozeiko On Feb 17, 2010, at 19:14 , Renato Golin wrote: >> Inline the init function: store 11 at the address of the "value" variable, >> call printf with the