search for: tmovi8

...from memory, or need multiple instructions to construct, it is reasonable to pre-compute them into registers, but for 8-bit immediate values, would it be more beneficial to load them directly in argument registers instead ? Looking at the ISel dump, for the above test-case: %0:tgpr, dead $cpsr = tMOVi8 10, 14, $noreg %1:tgpr, dead $cpsr = tMOVi8 20, 14, $noreg $r0 = COPY %0:tgpr $r1 = COPY %1:tgpr IIUC, there are a couple of reasons why this happens: (a) tMOVi8 pattern isn't marked with isRematerializable, isAsCheapAsMove, and isMoveImm. (b) After annotating the pattern with above flag...

...;def,dead> = tEOR %reg16388, %reg16387<kill>, pred:14, pred:%reg0 56L %reg16389<def> = COPY %reg16384<kill> 64L %reg16389<def>, %CPSR<def,dead> = tEOR %reg16389, %reg16386<kill>, pred:14, pred:%reg0 76L %reg16390<def>, %CPSR<def,dead> = tMOVi8 18, pred:14, pred:%reg0 88L %reg16391<def> = COPY %reg16390<kill> 96L %reg16391<def>, %CPSR<def,dead> = tEOR %reg16391, %reg16389<kill>, pred:14, pred:%reg0 108L %R0<def> = COPY %reg16391<kill> 116L %R1<def> = COPY %reg16388<kill>...

On Sat, Sep 4, 2010 at 1:31 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Sep 4, 2010, at 11:21 AM, Borja Ferrer wrote: > >> I've noticed this pattern happening with other operators aswell, but used xor in this example. As i said before, i tried with different register allocation orders, but it will produce always the same result. GCC is emitting longer

...to consider the surroundings, is it still > "trivial"? I honestly don't know right now. Hi Tim, Thanks for the response! Sorry, I didn't entirely understand why it isn't safe to propagate while checking for single live def, could you please elaborate ? IIUC, for above case, tmovi8 (movs) would update cpsr n/z flags, but since it's overwritten by following instructions, it's marked as dead in both cases ? The patch just checks that only one def is live and remaining defs of DefMI are dead in reMaterializeTrivialDef, in which case I assume it should be safe to propagat...

On Sep 4, 2010, at 11:21 AM, Borja Ferrer wrote: > I've noticed this pattern happening with other operators aswell, but used xor in this example. As i said before, i tried with different register allocation orders, but it will produce always the same result. GCC is emitting longer code, but since LLVM is so nearer to the optimal code sequence i wanted to reach it. In LLVM, copies are

...licit %r1, implicit-def %sp, implicit-def %r0, debug-location !25 DBG_VALUE 2, 0, !17, !18, debug-location !27 DBG_VALUE debug-use %r0, debug-use _, !16, !18, debug-location !26 tCMPi8 %r0, 2, 14, _, implicit-def %cpsr, debug-location !32 t2IT 11, 28, implicit-def %itstate %r0 = tMOVi8 _, 1, 11, %cpsr, implicit %r0, implicit %itstate tPOP_RET 11, %cpsr, def %r4, def %r6, def %r7, def %pc, implicit %r0, implicit %r4, implicit killed %itstate, debug-location !44 %r1 = t2MOVi 2, 14, _, _ t2B %bb.3.for.body, 14, _ Note that a terminator tPOP_RET is before a non-terminato...

> The right way to update the CFG very much depends on how you're > transforming it. I would like to export the CFG for control flow checking. Theoretically, it should be possible for a compiler to know every target of every control flow instruction, except for computed targets that are not known at compile-time. When a machine basic block is split between two branches, as shown below: