similar to: [LLVMdev] backend documentation

The Sparc port is maybe the closest thing to a text book example at this time. You can study it; debug some examples and trace through things. It's very simple because nobody is working on the Sparc port to make it a commercial compiler for the Sparc platform; yet at the same time it has complex patterns, custom inserters etc and all the elements of a more serious port. Most people learn

Hi Vadim, I am the book author of "Creating an LLVM Backend for the Cpu0 Architecture". Your question is right. More documents is good for programmer just like plentiful book in Linux Programming, even though the GCC backend compiler book is seldom. As you can see, I have let readers know how to write a RISC backend in my book but lack of the CISC backend features, like the complex

Hello everyone! I've started to implement a ColdFire backend, but there are some troubles during configuring: $ ../llvm/configure --enable-targets=x86,x86_64,coldfire ... ... ... checking whether byte ordering is bigendian... no configure: error: Unrecognized target coldfire configure: error: ../../../llvm/projects/sample/configure failed for projects/sample I've added ColdFire to : 1)

Hello developers! Could you, please, inform me about actual open projects? Where can I find this information? Does this list contains up to date information http://llvm.org/OpenProjects.html#new ? -- Regards, Vadim. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120922/3db4debe/attachment.html>

On 9/22/12 9:01 AM, Vadim Khoptynets wrote: > Hello developers! > > Could you, please, inform me about actual open projects? Where can I > find this information? Does this list contains up to date information > http://llvm.org/OpenProjects.html#new ? I'm not sure if all of the information is up to date, but I suspect some of the items are still unimplemented. The best thing

Hello to everyone! I've configured LLVM by "../llvm/configure". But when I run "gmake", I receive compilation error: llvm[2]: Linking Debug+Asserts executable llvm-tblgen /home/poiuj/dev/llvm/build/Debug+Asserts/lib/libLLVMSupport.a(FormattedStream.o):(.debug_loc+0x2a8): undefined reference to `.LCfI21' collect2: error: ld returned 1 exit status gmake[2]: ***

Hi Jonathan, After reading/skimming through the official LLVM backend documents, I actually tried following your steps to write a new backend, but how to write td files still remains unclear. The details are not well explained, though I know most of them can be found in other documents or have already been documented somewhere in the LLVM source code or td files. For a beginner with no

On Fri, Feb 1, 2013 at 4:01 PM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Feb 01, 2013 at 04:43:59PM +0200, Vadim Khoptynets wrote: >> Hello everyone! >> >> I've started to implement a ColdFire backend, but there are some troubles >> during configuring: >> >> $ ../llvm/configure --enable-targets=x86,x86_64,coldfire >> ... >>

Hello everyone! There is segmentation fault during translating a simple function with my backend. Investigation with gdb has shown that address of InstrNameData array in generated file MyTargetGenInstrInfo.inc is out of bounds. Also, if I run llc without -view-dag options, NumOpcodes equals 0 inside llvm::MCInstrInfo::get function, although there are some instructions (they are appeared in

Hello everyone! Could somebody advice me, how can I run llvm-tblgen to get MyTargetGenRegisterInfo.inc file to include in MyTargerRegisterInfo.h ? Unfortunately, I haven't found this information in "Writing an LLVM Compiler Backend" and "TableGen Fundamentals". -- Regards, Vadim. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, Feb 01, 2013 at 04:43:59PM +0200, Vadim Khoptynets wrote: > Hello everyone! > > I've started to implement a ColdFire backend, but there are some troubles > during configuring: > > $ ../llvm/configure --enable-targets=x86,x86_64,coldfire > ... > ... > ... > checking whether byte ordering is bigendian... no > configure: error: Unrecognized target

On Aug 1, 2012, at 1:53 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > > Currently, we rely on switch tables to transform between formats. However, > we would like to have a different mechanism to represent these relationships > instead of switch tables. I am thinking of modeling these relations in > HexagonInstrInfo.td file and use TableGen to generate a table with

Hello everyone! After I've checked out Clang and Compiler-RT repositories, I receive this error during compilation: llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp: In member function 'bool {anonymous}::CompareDiagnostics::operator()(const clang::ento::PathDiagnostic*, const

Hi Vadim, which compiler are you using to to the build, what platform are you on, how did you configure LLVM, clang etc ? Ciao, duncan. On 09/09/12 03:36, Vadim Khoptynets wrote: > Hello everyone! > > After I've checked out Clang and Compiler-RT repositories, I receive this error > during compilation: > > llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build >

Hi, I'm looking for some suggestions on a problem related to the Hexagon backend. Hexagon architecture allows instructions in various formats. For example, we have 3 variations of the add instruction as defined below: ADDrr : r1 = add(r2, r3) --> add 2 32-bit registers ADDrr_p : if(p0) r1 = add(r2, r3) --> predicated version of ADDrr instruction, executed when p0 is true ADDrr_np :

Hi all, I am trying to implement an instruction with no operand for example "clr" in TableGen. ----------------------------------------- e.g. *InstrInfo.td:* class TestInst<string opc, string asmstr, dag oops, dag iops, list<dag> pattern> : Instruction { ... } def int_no_operand : Intrinsic<[]>; class ALU<string opc> : TestInst<opc,

Hi Eli, >>>> 2. Storing arbitrary sized integers >>>> >>>> The testcase "test/CodeGen/Generic/APIntLoadStore.ll" checks for >>>> loading/storing e.g. i33 integers from/into global variable. The >>>> questions are the same as regarding feature 1: How important is this >>>> feature? Is it save to ignore it? Is there

Fabian, > here are the definitions of these register classes: > > // Data register class > def DR : RegisterClass<"TriCore", [i32], 32, > (add D0, D1, D2, D3, D4, D5, D6, D7, > D8, D9, D10, D11, D12, D13, D14, D15)>; > > // Extended-size data register class > def ER :

Hi Fabian, Anton, On 22/08/2012 08:25, Fabian Scheler wrote: >>> here are the definitions of these register classes: >>> >>> // Data register class >>> def DR : RegisterClass<"TriCore", [i32], 32, >>> (add D0, D1, D2, D3, D4, D5, D6, D7, >>> D8, D9, D10, D11, D12, D13, D14,

Hi Eli, thank you for the information. >> thanks to kind help of the LLVM-community I was able to bring my >> TriCore back-end a huge step forward, however I am not done, so far. I >> still miss the following features and maybe you could again provide me >> some help: >> >> 1. Passing return values on the stack >> >> Describing the calling