similar to: [LLVMdev] target feature matrix

On 24 October 2010 17:21, Chris Lattner <clattner at apple.com> wrote: > I just added this table: > http://llvm.org/docs/CodeGenerator.html#targetfeatures Hi Chris, That's great! I didn't know ARM back-end had support for inline assembly. If there is no assembly parser, does it call gas in a special way? -- cheers, --renato http://systemcall.org/ Reclaim your digital

On Sun, Sep 5, 2010 at 1:02 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > > I've carefully studied the source code of CGDebugInfo in clang as a > working > > example. One puzzlement is that there's a discrepancy between what the > > "source level debugging with LLVM" docs

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

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 export debug symbols in definitions, not declarations. I may be doing wrong, though, for multi-file compilation (haven't tested

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

If llvm compiler mis compiles a code then it is unlikely to be a bug in IRBuilder. Most likely it could be a bug in FE's use of IRBuilder or codegen/optimization bug. In either case IRBuilder won't save you. Same is true for DIFactory. It is a utility to construct MDNodes. It does not strictly enforce semantic correctness of debug info. (In fact, it is on my list somewhere to absorb

On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > I've carefully studied the source code of CGDebugInfo in clang as a working > example. One puzzlement is that there's a discrepancy between what the > "source level debugging with LLVM" docs say and what clang does: According > to the docs, DW_TAG_formal_parameter is used to specify a formal

I hate to be a nag, but after several days of working on this I am still utterly stumped. Let me recap the situation as it currently stands: I'm trying to write code that generates DWARF debugging information for my compiler using DIFactory and friends. Unfortunately the information I am generating appears to be invalid, but I can't figure out the cause. Based on the advice in the

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

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)

Hi, I'm trying to compile two files together with debug information but seems that LLVM is getting the DW_AT_stmt_list wrong when ld is linking the final executable. Originally, I tried on ARM with Clang (+llc+gas+ln) and, the object files, the DW_AT_stmt_list were null, as expected. When linking, they should point to the offset in the line table, but all of them are still null, so pointing

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 Nov 1, 2011, at 11:44 AM, Tony Linthicum wrote: > Hello all, > > We would like to contribute a new backend for Qualcomm's Hexagon > processor. We will actively maintain the port once it is accepted. > Hexagon is a VLIW core that is used principally in modem and low power > audio applications in Qualcomm's chip sets. > > We have a patch for both llvm and for

On 11/1/2011 3:46 PM, Chris Lattner wrote: > > If relevant, I'd suggest splitting it up as: > > 1. Changes to LLVM code outside your target directory. > 2. Your new target directory. > 3. Clang patches. > > As others have pointed out, you really do need some basic regression tests to make sure that the backend is working. Also, make sure to update this: >

There used to be a list of all the llvm ports and the status. The x86 was the only compiler that was a "full port". We are preparing to add out native linux compiler to the official build bots. Are there various official "gating" criteria for different levels of llvm "doneness" so to speak? There is a matrix I see in

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

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