similar to: [LLVMdev] Flash player with LLVM backend

On 21 September 2010 18:03, Bob Wilson <bob.wilson at apple.com> wrote: > Because that is what ARM has specified?  They define the vector types that are used with their NEON intrinsics as "containerized vectors".  Perhaps someone on the list from ARM can explain why they did it that way. That's ok, but why do you need to do that in the IR? I mean, in the end, the

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

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

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()); >

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

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

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

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

What exactly is M in that code you posted? Oleg Knut wrote: > > 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?

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

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

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

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