search for: movi32imm

...i32 %add, i32* %z, align 4 %2 = load i32, i32* %z, align 4 %call = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([18 x i8], [18 x i8]* @.str, i32 0, i32 0), i32 %2) ret i32 0 } Generated machine instructions (initial) BB#0: derived from LLVM BB %entry %vreg11<def> = MOVi32imm 6; GPR32:%vreg11 %vreg12<def> = MOVi32imm 5; GPR32:%vreg12 STRWui %WZR, <fi#0>, 0; mem:ST4[FixedStack0] STRWui %vreg12, <fi#1>, 0; mem:ST4[FixedStack1] GPR32:%vreg12 STRWui %vreg11, <fi#2>, 0; mem:ST4[FixedStack2] GPR32:%vreg11 ..................

Hello LLVM, I'm playing with a new ISD::OPAQUE instruction to make hoisting first class and eliminate a lot of tweaky flag setting/checking around opaque constants. It's going well for the IR and x86, but I now I need to sort out details for all the other targets. To start, can someone please advise on the AAarch64 equivalent of these X86 patterns? // Opaque values become mov immediate

On 8 March 2014 00:53, Owen Anderson <resistor at mac.com> wrote: > ISDOpcodes.h contains what documentation there is on the semantics of each > opcode. And TargetOpcodes.h for a few of the post-ISel ones (mostly they're in MachineInstr form, but you'll see them with -view-sched-dags, and occasionally before). Tim.

...GISel.inc, I see: /*56478*/ /*SwitchOpcode*/ 13, TARGET_VAL(ISD::GlobalAddress),// ->56494 /*56481*/ OPC_RecordNode, // #0 = $src /*56482*/ OPC_CheckType, MVT::i32, /*56484*/ OPC_CheckPatternPredicate, 4, // (!Subtarget->isThumb()) /*56486*/ OPC_MorphNodeTo, TARGET_VAL(ARM::MOVi32imm), 0, 1/*#VTs*/, MVT::i32, 1/*#Ops*/, 0, // Src: (globaladdr:i32):$src - Complexity = 3 // Dst: (MOVi32imm:i32 (globaladdr:i32):$src) The first lines are fairly unimportant, but the last two show what the DAG thinks it's doing and make it clear why...

...d-egg problem where neither can be hoisted without the other, and MachineLICM is not aggressive enough to recognize chains of dependent, loop-invariant cheap instructions. At the time, the advice was to implement a PseudoInstruction for lui+ori and lower it in a C++ pass, as is done in ARM (see MOVi32imm in ARMInstrInfo.td and ARMExpandPseudoInsts.cpp). I did this for my target and it worked fine, so MIPS could do the same. To me, that solution isn't too satisfying because you have to do this for every multi-instruction TableGen pattern to get them hoisted out of loops, but the philosophy se...

...while still performing the hoist in situations where register pressure is low enough? Say, considering the instructions in a loop for hoisting in descending order of cost, rather than in program order? Note that ARM gets around this by creating a pseudo-instruction for 32-bit immediate loads (MOVi32imm) , rather than putting a pattern directly in ARMInstrInfo.td. This fused instruction *is* rematerializable (since it defines the entire register), even though either of the two half-register instructions by themselves cannot be. This is one way my target and Mips could hack around the problem...

...ISEL: Match complete! ISEL: Starting pattern match on root node: 0x1e78210: i32 = ARMISD::Wrapper 0x1e77f10 [ID=9] Initial Opcode index to 49796 OpcodeSwitch from 49799 to 49891 Skipped scope entry (due to false predicate) at index 49896, continuing at 49914 Morphed node: 0x1e78210: i32 = MOVi32imm 0x1e77f10 ISEL: Match complete! Here is the failing case in Thumb2 mode ISEL: Starting pattern match on root node: 0x22f0f10: i32,ch = load 0x22c10b0, 0x22ee330, 0x22ee430<LD4[ConstantPool]> [ID=10] Initial Opcode index to 24668 Match failed at index 24684 ..... Continuing at 26993...

...instructions I caused to be generated. I forced the LDRi12 instructions to use a GPRPair sub-register. The copy into %vreg4 asserts because of the two definitions of vreg9, coming from vreg9:gsub_0 and vreg9:gsub_1. %vreg1<def> = COPY %R1; GPR:%vreg1 %vreg2<def> = MOVi32imm <ga:@a>; GPR:%vreg2 %vreg3<def> = ADDrsi %vreg2<kill>, %vreg1, 18, pred:14, pred:%noreg, opt:%noreg; GPR:%vreg3,%vreg2,%vreg1 %vreg9:gsub_0<def,read-undef> = LDRi12 %vreg3, 112, pred:14, pred:%noreg; mem:LD4[%arrayidx83](tbaa=!"int") GPRPair:%vreg...

...r32 7376B %424:gpr32 = COPY %422:gpr32 7384B %419:gpr32 = COPY %417:gpr32 7392B %414:gpr32 = COPY %412:gpr32 7400B %409:gpr32 = COPY %407:gpr32 7408B %404:gpr32 = COPY %402:gpr32 7416B %399:gpr64 = COPY %397:gpr64 7424B %394:gpr32 = COPY %392:gpr32 7528B %253:gpr32 = MOVi32imm 28 7536B STRWui %253:gpr32, %182:gpr64common, 2 :: (store 4 into %ir.106, align 8) 7752B %392:gpr32 = COPY %394:gpr32 7756B %397:gpr64 = COPY %399:gpr64 7764B %402:gpr32 = COPY %404:gpr32 7768B %407:gpr32 = COPY %409:gpr32 7776B %412:gpr32 = COPY %414:gpr32 7780B %417:gp...

On Apr 24, 2012, at 11:48 PM, Fan Dawei wrote: > For the following code fragment, > > ; <label>:27 ; preds = %27, %entry > %28 = load volatile i32* inttoptr (i64 2149581832 to i32*), align 8 > %29 = icmp slt i32 %28, 0 > br i1 %29, label %27, label %loop.exit > > loop.exit: ; preds = %27

...r32 7376B %424:gpr32 = COPY %422:gpr32 7384B %419:gpr32 = COPY %417:gpr32 7392B %414:gpr32 = COPY %412:gpr32 7400B %409:gpr32 = COPY %407:gpr32 7408B %404:gpr32 = COPY %402:gpr32 7416B %399:gpr64 = COPY %397:gpr64 7424B %394:gpr32 = COPY %392:gpr32 7528B %253:gpr32 = MOVi32imm 28 7536B STRWui %253:gpr32, %182:gpr64common, 2 :: (store 4 into %ir.106, align 8) 7752B %392:gpr32 = COPY %394:gpr32 7756B %397:gpr64 = COPY %399:gpr64 7764B %402:gpr32 = COPY %404:gpr32 7768B %407:gpr32 = COPY %409:gpr32 7776B %412:gpr32 = COPY %414:gpr32 7780B %417:gp...

Yes machine-licm can and should hoist constant materialization instructions out of the loop. If it's not doing that, it's probably because the target is not modeling the instruction correctly. I would walk through MachineLICM::IsLoopInvariantInst() in the debugger to figure it out. You can also try compiling the same bitcode for a target like ARM or X86 as a comparison. Evan On Mar 7,

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

For the following code fragment, ; <label>:27 ; preds = %27, %entry %28 = load volatile i32* inttoptr (i64 2149581832 to i32*), align 8 %29 = icmp slt i32 %28, 0 br i1 %29, label %27, label %loop.exit loop.exit: ; preds = %27 llc will generate following MIPS code, $BB0_1: lui $3, 32800 ori $3, $3, 1032 lw

Hi All, I work on a backend for a target similar to Mips, where large immediates are loaded into registers with 2 instructions, 1 to load the MSBits and 1 to load the LSBits. I've noticed a recurring pattern where, despite low register pressure, these constants will be rematerialized in every iteration of a loop, rather than being hoisted. Here's an example using the

Hello LLVM Developers, We are working on extending currently available register rematerialization to include cases where sequence of multiple instructions is required to rematerialize a value. We had a discussion on this in community mailing list and link is here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/subject.html#104777 >From the above discussion and studying the code we