similar to: [LLVMdev] IR type safety

Renato Golin wrote: > Hi folks, > > I have a few questions I was saving for later and never got around to > ask them, so I'll send a few emails to the list, one with each > question, to ease the further discussions that may come from them... > > The first question is: > > According to the language reference, LLVM IR is type safe. It means, > for instance, that you

On Sep 21, 2010, at 9:26 AM, Renato Golin wrote: > But, when declaring two types that happen to (supposedly) have the > same layout, LLVM ignores the second type and use the first's name > instead. > > In one module, it doesn't matter, but once you join different modules > with, possibly, different data layouts, the data types are not the > same any more. Try

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 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 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 27 September 2010 18:19, Bob Wilson <bob.wilson at apple.com> wrote: > I'm not sure what you mean by this.  The llvm intrinsics and built-in vector operations use plain vectors regardless of the front-end.  The structures are only relevant for things like argument passing and copying -- you can't do anything else with them.  Can you post an example of the 5X IR code size that

On 22 September 2010 03:43, Bob Wilson <bob.wilson at apple.com> wrote: > But regardless they are still structures, right?  What does it mean for them to map onto other types?  Is the parser supposed to treat them as if they _were_ those other types?  If so, I think you need to define a type system for those fundamental vector types.  I had read those statements to say something about the

On Sep 27, 2010, at 2:58 AM, Renato Golin wrote: > On 22 September 2010 03:43, Bob Wilson <bob.wilson at apple.com> wrote: >> But regardless they are still structures, right? What does it mean for them to map onto other types? Is the parser supposed to treat them as if they _were_ those other types? If so, I think you need to define a type system for those fundamental vector

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

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

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

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

Support for NEON intrinsics in clang is not complete. Poly types in general are known to be an issue, and the vceq_p8 in your example definitely needs an intrinisic. It should work with llvm-gcc. Can you clarify ARM's position on those structure types? It sounds like you are advocating that we get rid of them. The only reason we've been using them in llvm-gcc and clang is for

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