search for: isarm

...OVi16 (in ARMInstrInfo.td) which is defined as def MOVi16 : AI1<0b1000, (outs GPR:$Rd), (ins imm0_65535_expr:$imm), DPFrm, IIC_iMOVi, "movw", "\t$Rd, $imm", [(set GPR:$Rd, imm0_65535:$imm)]>, Requires<[IsARM, HasV6T2]>, UnaryDP { can be rewritten to this: class PredHasV6T2 { list<Predicate> Predicates = [HasV6T2]; } def MOVi16 : AI1<0b1000, (outs GPR:$Rd), (ins imm0_65535_expr:$imm), DPFrm, IIC_iMOVi, "movw", "\t$Rd, $imm",...

...ich is defined as > > def MOVi16 : AI1<0b1000, (outs GPR:$Rd), (ins imm0_65535_expr:$imm), > DPFrm, IIC_iMOVi, > "movw", "\t$Rd, $imm", > [(set GPR:$Rd, imm0_65535:$imm)]>, > Requires<[IsARM, HasV6T2]>, UnaryDP { > > > can be rewritten to this: > > class PredHasV6T2 { > list<Predicate> Predicates = [HasV6T2]; > } > > def MOVi16 : AI1<0b1000, (outs GPR:$Rd), (ins imm0_65535_expr:$imm), > DPFrm, IIC_iMOVi, >...

...t; > def MOVi16 : AI1<0b1000, (outs GPR:$Rd), (ins imm0_65535_expr:$imm), > > DPFrm, IIC_iMOVi, > > "movw", "\t$Rd, $imm", > > [(set GPR:$Rd, imm0_65535:$imm)]>, > > Requires<[IsARM, HasV6T2]>, UnaryDP { > > > > > > can be rewritten to this: > > > > class PredHasV6T2 { > > list<Predicate> Predicates = [HasV6T2]; > > } > > > > def MOVi16 : AI1<0b1000, (outs GPR:$Rd), (ins imm0_65535_expr:$imm), > >...

...mples in other *.td files. Here’s what I think I’m shooting for... /* Code in Target/ARM/ARMInstrInfo.td */ def ARMCFIID : AXI<(outs), (ins i32imm:$opt), MiscFrm, NoItinerary, "cfiid", "\t$opt", [(int_arm_cfiid i32imm:$opt)]>, Requires<[IsARM]> { bits<32> opt; let Inst{31-0} = opt; } ... I realize this is very wrong, but just to give you an idea of what I’m trying to do… basically take the i32 param of the intrinsic and encode it as a raw bytes. Obviously, this is broke… TL;DR: What’s the best way to lower an IR i32 into...

...ia. I'm not sure if the Arm code generators are doing this at all. > > Tia for any input. In terms of the instruction descriptions, ARM/Thumb basically has both instruction descriptions embedded into the same set of .td files, and all the instructions are marked with a predicate, either [IsARM] or [IsThumb]. Depending on the computed target, the compiler knows which kind of instructions generate, and the assembler knows how to switch where appropriate. There isn't really anything tricky here. The one key missing bit from what you're describing is that we don't have support...

We are starting to look at the mips16 and micro mips ports. There are various design issues that people may have some good input on. Especially in how to structure the TD files and other optimizer issues. Mips16 is sort of like thumb and Micro Mips like thumb2 as far as I understand. Mips16 or Micro Mips can live inside of either MIPS32 or MIPS64. In gcc, it's possible using attributes to

...---------------------------------------------------------------------------------------------------------- >>> When i checked from the ARM Lowering part for generation of >>> sub sp, sp, #16 >>> Emitted by, >>> if (VARegSaveSize) >>> emitSPUpdate(isARM, MBB, MBBI, dl, TII, -VARegSaveSize, // --> VARegSaveSize is calculated in computeRegArea >>> MachineInstr::FrameSetup) >>> >>> ARMTargetLowering::computeRegArea(..) { >>> ... >>> VARegSize = NumGPRs * 4; >>> VA...

...t going wrong. > ------------------------------------------------------------------------------------------------------------------------------ > When i checked from the ARM Lowering part for generation of > sub sp, sp, #16 > Emitted by, > if (VARegSaveSize) > emitSPUpdate(isARM, MBB, MBBI, dl, TII, -VARegSaveSize, // --> VARegSaveSize is calculated in computeRegArea > MachineInstr::FrameSetup) > > ARMTargetLowering::computeRegArea(..) { > ... > VARegSize = NumGPRs * 4; > VARegSaveSize = (VARegSize + Align - 1) & ~(Al...

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/5b2a15e3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201306181656803_BEI0XT4N.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/5b2a15e3/attachment.gif>

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

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

...>>>> > >>>> When i checked from the ARM Lowering part for generation of > >>>> sub sp, sp, #16 > >>>> > >>>> Emitted by, > >>>> > >>>> if (VARegSaveSize) > >>>> emitSPUpdate(isARM, MBB, MBBI, dl, TII, -VARegSaveSize, > >>>> // --> VARegSaveSize is calculated in computeRegArea > >>>> MachineInstr::FrameSetup) > >>>> > >>>> ARMTargetLowering::computeRegArea(..) { > >>>> ... > &g...