similar to: [LLVMdev] Lowering "memcpy" intrinsic function on ARM using LDMIA/STMIA

09.02.2011 18:57, Jason Kim пишет: > On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin > <vasiliy.korchagin at gmail.com> wrote: >> Hi, >> >> llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and > > Hmm, this happens elsewhere as well (x86?). Perhaps what we need is a > switch to disable memset/memcpy lowering? > Do you

-fno-builtin is the flag you want. deep On Wed, Feb 9, 2011 at 10:18 PM, Корчагин Василий <vasiliy.korchagin at gmail.com> wrote: > 09.02.2011 18:57, Jason Kim пишет: >> On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin >> <vasiliy.korchagin at gmail.com>  wrote: >>> Hi, >>> >>> llvm emits code for "memcpy" on ARM as consecutive

On Wed, Feb 9, 2011 at 5:02 AM, Vasiliy Korchagin <vasiliy.korchagin at gmail.com> wrote: > Hi, > > llvm emits code for "memcpy" on ARM as consecutive ldr/str commands, and Hmm, this happens elsewhere as well (x86?). Perhaps what we need is a switch to disable memset/memcpy lowering? > further combines them into ldm/stm with special pass after register >

On 01.07.2011 12:03, Eli Friedman wrote: > On Fri, Jul 1, 2011 at 12:53 AM, Корчагин Василий > <vasiliy.korchagin at gmail.com> wrote: >> Hello, LLVMdev. >> >> The problem is that C backend doesn't support integers wider than 64 >> bits, but I need to use it on programs with wide integers in LLVM IR. My >> question is how to deny LLVM to generate wide

On 1 July 2011 13:35, Vasiliy Korchagin <vasiliy.korchagin at gmail.com> wrote: > On 01.07.2011 12:03, Eli Friedman wrote: >> On Fri, Jul 1, 2011 at 12:53 AM, Корчагин Василий >> <vasiliy.korchagin at gmail.com>  wrote: >>> The problem is that C backend doesn't support integers wider than 64 >>> bits, but I need to use it on programs with wide

hello vorlon, got notified of your patch, will apply next days upstream unless some critiques are voiced on ml. thanks. -- maks ----- Forwarded message from Steve Langasek <steve.langasek at canonical.com> ----- Date: Wed, 16 Feb 2011 22:05:42 -0000 From: Steve Langasek <steve.langasek at canonical.com> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses

07.02.2012 07:27, Eli Friedman пишет: > On Mon, Feb 6, 2012 at 6:51 PM, Xin Tong<xerox.time.tech at gmail.com> wrote: >> Is there any way to stop this ? >> >> /home/socrates/llvm/llvm-3.0.src/benchmarks/powerstone/crc/crc.c:67:1: >> error: 'main' must return 'int' >> void main() >> ^ >> 1 error generated. > You mean besides

Hello, LLVMdev. The problem is that C backend doesn't support integers wider than 64 bits, but I need to use it on programs with wide integers in LLVM IR. My question is how to deny LLVM to generate wide integer? Which part of LLVM should I modify? Best regards, V. Korchagin.

Hello to all. When studying forums and mailing lists it seems to me that llvm usage for very small arm v6m targets is not so common. In the last months, I have spent some time on analyzing performance of llvm/clang for very small targets. My main objective was to get the best possible performance from portable (non-assembly) crypto numerics for cortex-M0(+) targets. As a result (crypto

Greetings Sandeep I have tested crosscompiling llvm2.6 svn trunk 69279 + your patch for armv7a hardware. I wanted to see if it would build and if any unexpected failing tests in the testsuite would start to work using your patch. It built fine and your attached tests in the patch runs fine for me :) Now something fun this Generic test now works that previously failed: $ llvm-as <

Hi, After Bob fixed the two-address format of the ARM ldm/stm instructions, a problem remains. The load multiple instruction looks like: // A list of registers separated by comma. Used by load/store multiple. def reglist : Operand<i32> { let PrintMethod = "printRegisterList"; } def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, reglist:$dsts,

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.

Am Mittwoch, 26. September 2012, 11:18:20 schrieb Jakob Stoklund Olesen: > Hi Christoph, > > As you noticed, MCInstrDesc doesn't distinguish between variadic uses and > defs. Since variadic instructions will always require some kind of special > handling, it doesn't seem worthwhile to make the model more detailed. I don't see what makes them so different from other

On Fri, Jul 1, 2011 at 12:53 AM, Корчагин Василий <vasiliy.korchagin at gmail.com> wrote: > Hello, LLVMdev. > > The problem is that C backend doesn't support integers wider than 64 > bits, but I need to use it on programs with wide integers in LLVM IR. My > question is how to deny LLVM to generate wide integer? Which part of > LLVM should I modify? scalarrepl is the

I'm trying to figure out how to map more complex CISC instructions now. For example on the 68000, you have things like -- add.w (a0)+,(a1)+ So that equates to: temp1 = load a0 add 2, a0 temp2 = load a1 temp1 = add temp1, temp2 store temp1, a1 add 2, a1 How do I express that in a form for LLVM? I see things like pre_store and post_store, but I cant find anything in the way of documentation

On Mar 19, 2010, at 7:46 AM, Jakob Stoklund Olesen wrote: > Hi, > > After Bob fixed the two-address format of the ARM ldm/stm instructions, a problem remains. The load multiple instruction looks like: > > // A list of registers separated by comma. Used by load/store multiple. > def reglist : Operand<i32> { > let PrintMethod = "printRegisterList"; > }

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

Hallo, I worked on how to handle the distinction between variadic defines and uses and my current solution is this: I introduce a new dag item in Instruction called VariadicOperandList, which by default is undefined. It keeps a marker variable_* and all operands which are placeholders for variable lists (like 'reglist' on ARM). I think it's the cleanest solution to keep them in a

Was it the subreg lane masks / mapping that was added to address the missed coalescing? This solution is nice, but I don't think it'll work for me. I have 8-element vector registers that can be grouped into virtual super regs for bulk save/restore, and as soon as I have more than 4 in a tuple, the unsigned int used to hold the lane masks overflows and switches over to the "bit 31 set

arm: implement exception and hypercall entries. xen/arch/arm/xen/Makefile | 3 + xen/arch/arm/xen/asm-offsets.c | 61 ++++++++ xen/arch/arm/xen/entry.S | 596 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ xen/arch/arm/xen/hypercalls.S | 67 +++++++++ xen/arch/arm/xen/physdev.c | 41 +++++ 5 files changed, 768 insertions(+), 0