search for: arminstrformats

Hi, I wonder whether I can conditionally set AsmString in class sI. For instance, I would like to know whether it is possible to establish some int or bit operator to check whether bits<4> p is 14. What I would like to do is to set AsmString as follows, class sI<...> :InstARM<....> { ... let AsmString = !if(some operator, !strconcat(ppc, "${s}",

...ions is not the right thing to do. We've been trying hard to avoid adding those "twins". The instructions that can optionally set the condition codes have an "optional def" operand. For example, look at the "cc_out" operand in the "sI" class defined in ARMInstrFormats.td. If that operand is set to the CPSR register, then the instruction becomes the "s" variant. There are some existing peephole optimizations to make use of this, but there are some unresolved issues as well. Do you have some example testcases that show where we're missing opportun...

Hello everyone, I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Besides, I propose the codegen optimization based on them, which removes the redundant comparison in patterns like orr

Thank you for your help Tom you are totally right with the registers but the command you suggest also doesn't work. After some research I found the following thread on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110086.html With your help and the information about the condition codes I was able to resolve the error:         BuildMI(BB, BB.end(), DL,

Hi, I haven't been able to reproduce this problem on a smaller test and the original source code is from another virtual machine's IR. What I found out was that 42 << 7 is actually DPSoRegImmFrm, defined in ARMInstrFormats.td. This format is not dealt with in the ARMCodeEmitter.cpp and that's the problem I'm facing. The triple I'm using is "armv7-unknown-linux-gnueabi" and the bitcode I'm dealing with is: ; ModuleID = 'CRYO jit' target triple = "armv7a-unknown-linux-gnueabi&...

...ames Molloy; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] ARM opcode format Hi, I haven't been able to reproduce this problem on a smaller test and the original source code is from another virtual machine's IR. What I found out was that 42 << 7 is actually DPSoRegImmFrm, defined in ARMInstrFormats.td. This format is not dealt with in the ARMCodeEmitter.cpp and that's the problem I'm facing. The triple I'm using is "armv7-unknown-linux-gnueabi" and the bitcode I'm dealing with is: ; ModuleID = 'CRYO jit' target triple = "armv7a-unknown-linux-gnueabi&...

On 7/10/2015 10:23 AM, Sky Flyer wrote: > Many thanks for your prompt reply. > > I mean, imagine you have 3 bits for condition flags in your instruction > (e.g. overflow, zero, carry set, ...) for conditional executions AND > there is no direct access to the Status Register, is it even possible to > implement such scenario? > There doesn't have to be any explicit status

...e format**** > > ** ** > > Hi,**** > > ** ** > > I haven't been able to reproduce this problem on a smaller test and the > original source code is from another virtual machine's IR. What I found out > was that 42 << 7 is actually DPSoRegImmFrm, defined in ARMInstrFormats.td. > This format is not dealt with in the ARMCodeEmitter.cpp and that's the > problem I'm facing.**** > > ** ** > > The triple I'm using is "armv7-unknown-linux-gnueabi" and the bitcode I'm > dealing with is:**** > > ** ** > > ; ModuleID...

Many thanks for your prompt reply. I mean, imagine you have 3 bits for condition flags in your instruction (e.g. overflow, zero, carry set, ...) for conditional executions AND there is no direct access to the Status Register, is it even possible to implement such scenario? On Fri, Jul 10, 2015 at 4:54 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 7/10/2015 9:32