search for: cpsr

All, ARM LLVM afficianados: I'm trying to understand how LiveVariables computes liveness for CPSR. In particular, I would like to tell whether a particular instruction is a use/kill/def for doing some within block liveness checking I need. Thanks in advance, David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/atta...

...or2 } produces these instructions before coalescing: 4L %reg16387<def> = COPY %R3<kill> 12L %reg16386<def> = COPY %R2<kill> 28L %reg16384<def> = COPY %R0<kill> 36L %reg16388<def> = COPY %reg16385<kill> 44L %reg16388<def>, %CPSR<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>...

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

..."r" (val) : "memory"); } ------------------------ # *** IR Dump Before Post RA top-down list latency scheduler ***: BB#6: derived from LLVM BB %if.else Live Ins: %LR %R2 %R3 %R4 %R7 %R12 Predecessors according to CFG: BB#0 CMPri %R12, 1, pred:14, pred:%noreg, %CPSR<imp-def> <<<<<<<<<<< First comparison using lock_flag ; R12 holds lock_flag %R5<def> = IMPLICIT_DEF Bcc <BB#21>, pred:1, pred:%CPSR<kill> <<<<<<<<<<< Successors according to CFG: BB#7(0x400...

...ev at lists.llvm.org> wrote: > > (b) Modifies RegisterCoalescer::reMaterializeTrivialDef and > > TargetInstrInfo::isReallyTriviallyReMaterializableGeneric to check > > for single live def, instead of single def. > > This seems dodgy to me. The instruction does also change CPSR so for > the transformation to be valid you have to know that register is dead > where the new instruction is being inserted. As far as I can tell the > hasOneDef check in reMaterializeTrivialDef is a simple heuristic to > keep the analysis local and avoid dealing with such issues. >...

...derived from LLVM BB %cond.end Live Ins: %LR %R0 %R1 %R7 %R10 %R11 Predecessors according to CFG: BB#14 BB#18 STRi12 %R7<kill>, %R1, 0, pred:14, pred:%noreg; mem:ST4[%first257](tbaa=!"int") %R1<def> = ADDri %R1<kill>, 4, pred:14, pred:%noreg, opt:%CPSR<def> Bcc <BB#23>, pred:0, pred:%CPSR<kill> B <BB#22> Successors according to CFG: BB#23 BB#22 # After ARMLoadStoreOptimizer: BB#21: derived from LLVM BB %cond.end Live Ins: %LR %R0 %R1 %R7 %R10 %R11 Predecessors according to CFG: BB#14 BB#18...

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

...%15](align=4) > %R3<def> = EORri %R6, 254, pred:14, pred:%noreg, opt:%noreg > %R3<def> = ANDrr %R3<kill>, %R6<kill>, pred:14, pred:%noreg, opt:%noreg > %R6<def> = MOVi 0, pred:14, pred:%noreg, opt:%noreg > TSTri %R3<kill>, 255, pred:14, pred:%noreg, %CPSR<imp-def>; > Bcc <BB#9>, pred:0, pred:%CPSR<kill>; > > BB#8: > Live Ins: %LR %R0 %R1 %R2 %R4 %R5 %R6 %R7 %R8 %R9 %R10 %R12 > Predecessors according to CFG: BB#7 > STRi12 %R6, %R7<kill>, 4, pred:14, pred:%noreg; mem:ST4[%__size_.i3.i.i.i.i] > %R6<de...

...%cond.end > Live Ins: %LR %R0 %R1 %R7 %R10 %R11 > Predecessors according to CFG: BB#14 BB#18 > STRi12 %R7<kill>, %R1, 0, pred:14, pred:%noreg; mem:ST4[%first257](tbaa=!"int") > %R1<def> = ADDri %R1<kill>, 4, pred:14, pred:%noreg, opt:%CPSR<def> > Bcc <BB#23>, pred:0, pred:%CPSR<kill> > B <BB#22> > Successors according to CFG: BB#23 BB#22 > > # After ARMLoadStoreOptimizer: > BB#21: derived from LLVM BB %cond.end > Live Ins: %LR %R0 %R1 %R7 %R10 %R11 > Predece...

Hello. I've got the "unsigned int" register number. How one uses LLVM API to determine if that register is the status register (e.g., ARM::CPSR) or not? I know I can just compare the number with ARM::CPSR, but the code becomes not universal. I gave up searching for the solution by myself... Thanks.

...CFI_INSTRUCTION <call frame instruction>; flags: FrameSetup %R7<def> = tMOVr %SP<kill>, pred:14, pred:%noreg; flags: FrameSetup CFI_INSTRUCTION <call frame instruction>; flags: FrameSetup t2CMPri %R1<kill>, 0, pred:14, pred:%noreg, %CPSR<imp-def> t2CMPri %R0<kill>, 3, pred:1, pred:%CPSR, %CPSR<imp-def>, %CPSR<imp-use,undef> --> %SP<def,tied1> = t2LDMIA_RET %SP<tied0>, pred:8, pred:%CPSR, %R7<def>, %PC<def>, %SP<imp-use,undef>, %R7<imp-use,undef>, %PC<...

I see strangeness on Thumb TST (tTST) predicate 'isCompare' It is true for regular ARM, false for Thumb: (gdb) p MI->dump() TSTri %reg16397, 3, pred:14, pred:%reg0, %CPSR<imp-def>; GPR:% reg16397 $24 = void (gdb) p MI->getDesc().isCompare() $25 = true (gdb) p MI->dump() tTST %reg16396, %reg16397, pred:14, pred:%reg0, %CPSR<imp-def>; tGPR:%reg16396,16397 $22 = void (gdb) p MI->getDesc().isCompare() $23 = false Is this intentional or jus...

Doh. I missed the list in my first reply... Here's the replay of the conversation: ----- Renato: On 10 August 2015 at 14:05, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > --> %SP<def,tied1> = t2LDMIA_RET %SP<tied0>, pred:8, pred:%CPSR, > %R7<def>, %PC<def>, %SP<imp-use,undef>, %R7<imp-use,undef>, > %PC<imp-use,undef> > > Here the instruction t2LDMIA_RET is a terminator and yet it's followed by a > non-terminator tBLXi. This looks wrong. Does anyone have any comments on &...

...removes the redundant comparison in patterns like orr r1, r2, r3 ----> orrs r1, r2, r3 cmp r1, 0 This optimization has shown nice acceleration, e.g. 3.3% in SQLite on CortexA8 and works fine. I have some questions though. 1)"neverHasSideEffects" in tablegen means that CPSR is not implicitly defined, doesn't it? 2)What else can be done using that super "S" power? 3)Current optimization implementation works similar to peephole (peephole pitiful cmp optimization was disabled), right before ifcvt. Should I raise it up somewhere? What do you think is the rig...

...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 opportunities?

...Ins: %LR %R0 %R1 %R7 %R10 %R11 > > Predecessors according to CFG: BB#14 BB#18 > > STRi12 %R7<kill>, %R1, 0, pred:14, pred:%noreg; > mem:ST4[%first257](tbaa=!"int") > > %R1<def> = ADDri %R1<kill>, 4, pred:14, pred:%noreg, > opt:%CPSR<def> > > Bcc <BB#23>, pred:0, pred:%CPSR<kill> > > B <BB#22> > > Successors according to CFG: BB#23 BB#22 > > > > # After ARMLoadStoreOptimizer: > > BB#21: derived from LLVM BB %cond.end > > Live Ins: %LR %R0...

...LLVM BB @0x8fc2c48, ID#0: Live Ins: %R0 %R1 %reg1026<def,dead> = MOVr %R1<kill>, 14, %reg0, %reg0 %reg1025<def> = MOVr %R0<kill>, 14, %reg0, %reg0 %reg1024<def> = MOVr %reg1025, 14, %reg0, %reg0 CMPri %reg1025<kill>, 0, 14, %reg0, %CPSR<imp-def> Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill> Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2) bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: Predecessors according to CFG: 0x8fdac90 (#0) %reg1027<def> = MOVi 0, 14, %reg0, %r...

...it? > **** Post Machine Instrs **** > # Machine code for Insert(): > Live Ins: R0 in VR#1025 R1 in VR#1026 > > entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0: > Live Ins: %R0 %R1 > %LR<def> = MOVr %R0, 14, %reg0, %reg0 > CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def> > Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill> > Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2) > > bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: > Predecessors according to CFG: 0x8fdac90 (#0) > %R0<def> = MOVi...

On Sep 14, 2010, at 12:09 PM, Gabor Greif wrote: > I see strangeness on Thumb TST (tTST) predicate 'isCompare' > > It is true for regular ARM, false for Thumb: > > (gdb) p MI->dump() > TSTri %reg16397, 3, pred:14, pred:%reg0, %CPSR<imp-def>; GPR:% > reg16397 > $24 = void > (gdb) p MI->getDesc().isCompare() > $25 = true > > > (gdb) p MI->dump() > tTST %reg16396, %reg16397, pred:14, pred:%reg0, %CPSR<imp-def>; > tGPR:%reg16396,16397 > $22 = void > (gdb) p MI->getDesc(...

...R should be added to livein of BB #1. **** Post Machine Instrs **** # Machine code for Insert(): Live Ins: R0 in VR#1025 R1 in VR#1026 entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0: Live Ins: %R0 %R1 %LR<def> = MOVr %R0, 14, %reg0, %reg0 CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def> Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill> Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2) bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: Predecessors according to CFG: 0x8fdac90 (#0) %R0<def> = MOVi 0, 14, %reg0, %reg0...