similar to: [LLVMdev] building an ARM backend

On Mon, 2006-04-24 at 08:50, Rafael Espíndola wrote: > I have read the documentation and taken a look on the X86 back end. It > looks quiet simple to get a very minimal back end working. I am > considering for a first version: One of the RISC backends will make the work look a lot simpler :) > 1) only support the 32 bits ABI > 2) Ignore the shifter (i.e use only 8 bits immediates)

Rafael Esp?ndola wrote: > The company I work for uses quiet some ARM processors and I am trying > to convince them to let me spend some company time building an llvm > back end :-) Funny, I've just got one student for exactly same task -- writing ARM backend. Of course, the student might well disappear by the time new term begins and might not produce anything usable for a year ;-)

On 14 October 2013 21:56, reed kotler <rkotler at mips.com> wrote: > I would like to do constant pools over an entire module instead of just on a > per function basis as constant islands does it now. > > It seems there are two options for this: > > 1) collect the machine functions with their machine instructions for the > whole module, edit them as needed and then >

On Oct 15, 2013, at 1:30 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 14 October 2013 21:56, reed kotler <rkotler at mips.com> wrote: >> I would like to do constant pools over an entire module instead of just on a >> per function basis as constant islands does it now. >> >> It seems there are two options for this: >> >> 1)

I would like to do constant pools over an entire module instead of just on a per function basis as constant islands does it now. It seems there are two options for this: 1) collect the machine functions with their machine instructions for the whole module, edit them as needed and then call asmprinter for them one at a time. 2) collect all the instruction streams and store them in lists, one

Hi, On Wed, Jul 12, 2017 at 2:21 AM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks, Bruce. This is a very interesting optimization. > > lld doesn't currently have code to support that kind of code shrinking > optimization, but we can definitely add it. It seems that essentially we > need to iterate over all relocations while rewriting

On 25 September 2013 12:28, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, Sep 25, 2013 at 7:02 AM, Renato Golin <renato.golin at linaro.org> > wrote: >> > (Devil's advocate, but half serious): > > It may be a good idea to require that the dummy backend is kept up to date, > as a way to keep a pulse on changes to the interfaces between

Hi, Andrew Lenharth wrote: > On Mon, 2006-04-24 at 08:50, Rafael Espíndola wrote: > > I have read the documentation and taken a look on the X86 back end. > > It looks quiet simple to get a very minimal back end working. I am > > considering for a first version: > > One of the RISC backends will make the work look a lot simpler :) Is it true that the new Sparc one is

# Summary As a consequence of comparing the RISC-V LLVM MC assembler to the RISC-V GNU assembler I've noticed that a number of targets have quite different handling for pc-relative jumps/branches with immediate integer operands in llvm-mc vs GNU as. I'll admit that this isn't likely to occur in hand-written code (as you'd almost always prefer to use a label), but thought it was

I forgot to mention that I used EXTRACT_ELEMENT in my backend to get the high and low parts of an SDValue. On 10 Nov 2013, at 17:50, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > I had a similar problem with a backend for the 68HC12 family which also has no barrel shifter. Some 68HC12 CPUs support shift for just one of the 16-bit registers and only support rotation

> You get the code you want with > > @foo = external hidden global i8 > > or > > @foo = external protected global i8 Sorry, not quiet. What you get is leaq foo(%rip), %rax Since it is still assuming foo is a position in the file. So yes, we need a way to declare an absolute value. If we can declare it, we may as well use the same construct to define it. I guess the

Here's an example using the gcc toolchain for embedded 32 bit RISC-V (my HiFive1 board): #include <stdio.h> int foo(int i){ if (i < 100){ printf("%d\n", i); } return i; } int main(){ foo(10); return 0; } After compiling to a .o with -O2 -march=RV32IC we get (just looking at foo) 00000000 <foo>: 0: 1141 addi sp,sp,-16

Chris Lattner wrote: > > 1. The MachineInstrBuilder has methods to add register operand and > > immediate operand. However, what would be really nice is a method to add > > Value*. So, I would write: > > > > BuildMI(*BB, NM::add, 1).add(I.getOperand(0), I.getOperand(1)); > > > > and depending on whether the passed Value* is contant or instruction,

Dear All, I am trying to custom lower 32-bit ISD::SHL and SHR in a backend for 6502 family CPUs. The particular subtarget has 16-bit registers at most, so a 32-bit result is not legal. Normally, if you mark this as "Legal" or "Expand", then it will expand the node into a more nodes as follows in an example: shl i32 %a , 2 => high_sdvalue = (or (shr %b, 14), (shl %c, 2) )

Hi Steve, Thanks for confirming that EXTRACT_ELEMENT is something I can use. I had seen it in the generated DAGs but was unsure whether I was "allowed" to use it, if that's the right word. I checked up on it more and indeed the mainstream targets like ARM use that node type in custom lowering code, so that should solve that. Perhaps in the future I might submit a patch for

> "The destination register shall not be the same as the operand > register Rm. R15 shall not be used as an operand or as the > destination register." The ARM ARM has this "Operand restriction" on MUL: Specifying the same register for <Rd> and <Rm> has UNPEDICTABLE results. > Then, for the load and store multiple instructions, LDM and STM,

Hello, I'm working on an LLVM backend for an experimental microprocessor. Work is going on nicely, and I've until now found the answer to all my questions directly in the LLVM source code, or in the documentation. However, I'm having problems with the AsmBackend class and the handling of fixups. The processor I'm working with has a single conditional branch instruction, JCC,

Hi Chris, > On Sun, 17 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > > The ARM has a multiply instruction of the form Rd=Rm*Rs where Rd != > > Rm. How can I add this requirement to the instruction definition? > > ... > > I'd like to make the regalloc interfaces more powerful to be able to > capture this sort of thing, but I'm not very familiar with ARM.

On 16 January 2017 at 15:31, Sean Silva <chisophugis at gmail.com> wrote: > Do we have any open projects on LLD? > > I know we usually try to avoid any big "projects" and mainly add/fix things > in response to user needs, but just wondering if somebody has any ideas. > > Some really generic/simple stuff I can think of: > 1. trying out LLD on a large program

In r198030 the last in tree backend was converted to use MCInst for printing assembly. I removed support for the old printer in r198959. Out of tree targets have to lower MachineInstr to MCInst to use the new printer. Cheers, Rafael