similar to: [LLVMdev] Howto Guide on Porting the LLVM Assembler

Yes, please do. Simon On Wed 17 Oct 2012 02:20:17 BST, Sean Silva wrote: > Wow this is awesome! Would it be okay if we linked to this from llvm.org/docs? > > -- Sean Silva > > On Tue, Oct 16, 2012 at 5:55 PM, Simon Cook <simon.cook at embecosm.com> wrote: >> Hi Everyone, >> >> I have been implementing the integrated assembler for the OpenRISC 1000 >>

Wow this is awesome! Would it be okay if we linked to this from llvm.org/docs? -- Sean Silva On Tue, Oct 16, 2012 at 5:55 PM, Simon Cook <simon.cook at embecosm.com> wrote: > Hi Everyone, > > I have been implementing the integrated assembler for the OpenRISC 1000 > architecture. > > Whilst doing this I noticed a lack of documentation around this area. To > help others,

Hi all, I am trying to compile with a minimal TestAsmParser class, but I get the following error. ---------------- [43/780] Linking CXX executable bin/llvm-mc FAILED: : && /usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11

Hi, I'm looking into development of an llvm-objdump utility for hexagon and I've read that there is a way to have tablegen automatically generate decode tables for you. I've not been able to find much info on this topic, the best info I've been able to find is this tutorial: http://www.embecosm.com/appnotes/ean10/ean10-howto-llvmas-1.0.html#idp3570032 I've managed to get

Hi Renato, Currently I am building a set of patches which will add AAP piece-wise. I'm following the approach that AVR (and now RISC-V), and the patches I plan on adding are as follows: * Target triple * ELF definition * Basic skeleton with the required build system changes (targetinfo + target machine) * Instruction + Register tablegen * MC layer support * AsmParser * InstPrinter *

Hi all, We wish to submit our latest AAP implementation as an experimental backend into LLVM. We need community feedback and reviewers for patches which we will submit soon. AAP was designed in early 2015 and aims to advance compiler development for small deeply embedded Harvard architectures, which are widely used commercially. AAP is freely available as an open source softcore for use in FPGA

(Sorry about the wall of text, it ended up as a brain dump of a bunch of backend-related documentation that I know about/have bookmarked in the past. Hopefully there's something useful in there.) If you haven't stumbled across them already, these might be helpful: http://llvm.org/devmtg/2009-10/Korobeynikov_BackendTutorial.pdf http://jonathan2251.github.io/lbd/

When I registered for dev conference, there was a field asking what I was particularly interested in learning. I didn't fill it out then , but it occurs to me now that I'd really enjoy a tutorial on how to develop a new back end. I spent some time recently reviewing existing material (documentation and code) and not making a lot of progress. Indeed, under some time pressure, I'm

On Thu, 2019-05-02 at 19:54 +0200, Pavel Šnobl wrote: > Hi Jesper, > > thank you for working on this. My company (Codasip) would definitely > be interested in having this feature upstream. I think that this is > actually important for a suprisingly large number of people who > currently have to maintain their changes downstream. I have a couple > of questions and comments:

What happened with this? Is there something for review in Phabricator? Or was this put-on-hold/forgotten? I also have some users that complain that some gdb test suite tests don't work with LLVM due to missing debug info regarding ending brace. So gettint the location for the "endLine" field of DISubprogram etc should at least be a step in the right direction, and if someone already

> Maybe this would make a good GSOC project. It's definitely too small project for a GSoC. One can try to start from https://github.com/asl/llvm-openrisc (openrisc branch inside), however, it's already 2 years old... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State Universit

Hi all, There are quite a few of us working on LLVM in the Bristol area. I invite you all to the first Bristol LLVM social: Where: The Hope & Anchor 38 Jacobs Wells Road Bristol BS8 1DR http://www.hopeandanchor.net When: Thursday 20 September from 7pm Look forward to meeting you all there. Jeremy -- Tel:

Hi all, I have just updated most of the patches to roll them forwards to LLVM top-of-tree, and incorporated various suggested changes. We're still looking for reviewers, if anyone is interested. Thank you, Edward Jones On 15/09/16 17:12, Ed Jones wrote: > I have now posted the final two patches for the backend to add > Disassembler support, ISel and CodeGen. The full list of patches

Hi, While crosscompiling the kernel for openrisc with allmodconfig the build failed with the error: drivers/vhost/vhost.c: In function 'vhost_vring_ioctl': drivers/vhost/vhost.c:818:3: error: call to '__compiletime_assert_818' declared with attribute error: BUILD_BUG_ON failed: __alignof__ *vq->avail > VRING_AVAIL_ALIGN_SIZE Can you please give me any idea about what the

Hi, While crosscompiling the kernel for openrisc with allmodconfig the build failed with the error: drivers/vhost/vhost.c: In function 'vhost_vring_ioctl': drivers/vhost/vhost.c:818:3: error: call to '__compiletime_assert_818' declared with attribute error: BUILD_BUG_ON failed: __alignof__ *vq->avail > VRING_AVAIL_ALIGN_SIZE Can you please give me any idea about what the

As it stands, the active customers for this target are the out-of-tree backends which we are working on which can't be submitted for inclusion into LLVM. The general aim of the backend though is to include features from architectures which are not well represented in LLVM, for example non-power of two register sizes, non-octet chars, or very constrained register sets, and to this end we hope

Hi, I'm working on a project that use llvm openrisc beckend (currently not part of the upstream). Right now I'm looking at a bug where llc generates memory instructions that has out-of-range displacement, for example l.sb 37668(r1), r2 in which 37668 is a 17 bit signed integer, but the instruction only allows 16 bit signed displacement. As a result, after running through the

The initial proposal to include AAP in LLVM met with some concern that it would be actively maintained (thread from http://lists.llvm.org/pipermail/llvm-dev/2016-August/103807.html ), and after some review activity seemingly went quiet (although review code has been updated quite recently). Is AAP likely to land any time soon? Also an AAP architecture question (possibly the wrong forum, though

> However, figuring out what can and cannot be deleted from the sparc backend > while still compiling is proving rather frustrating. Why are you looking into sparc backend? I believe the talk makes clear which backend should be considered as a start point (at that time). In any case, https://github.com/asl/llvm-openrisc is better "stub" backend, at least it's 'just' 6

Simon, I also think of the way you did. :-) And from my initial investigation, clang should also has some work(i.e. provide the end location for the "endLine" field of DISubprogram), right? BTW, Simon, your fork of LLVM is open source or not? If open source, could you give the address of it?  Thanks < Simon Cook via llvm-dev> 在 2017-08-04 00:10:59 写道: On 03/08/17 16:21,